Last Call Review of draft-kucherawy-dkim-atps-
review-kucherawy-dkim-atps-secdir-lc-polk-2012-01-05-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

This draft specifies a suite of mechanisms for "authorized" third party
DKIM signatures.  The suite of mechanisms includes:
(1) DNS TXT records advertising that a third party has been authorized to
apply DKIM signatures on behalf of the Administrative Mail Domain (ADMD);
(2) a pair of DKIM signature tags to specify (a) the domain of the ADMD on
whose behalf the signature was generated and (b) the selected hash
algorithm; and
(3) an algorithm for determining whether a third party signature should be
considered equivalent to a signature applied by the ADMD.

Since the working group did not have consensus that such a mechanism was
required, this document is intended for publication as an experimental RFC.

In my opinion, this document is appropriate and ready for publication as
an Experimental RFC.  I found it a nice straightforward read.  (Thanks!)
There are two issues that I would like to raise for discussion, though.

First, Section 4.3 states:

 "Note that the algorithm uses hashing, but this is not a security
mechanism.  See Section 9.2 for discussion."

However, Section 9.1 begins with:

 "The selection of the hash algorithm to be used (see Section 4.1) has
security implications, as weaker algorithms have more risk of collision
..."

This seems to be a contradiction of sorts!  If it has security
implications, isn't it a security mechanism?  The author should give some
thought to the properties they expect from the hash in this situation and
revise either 4.3 or 9.1.

Secondly, the more interesting issue (at least to me) is in Section 4.4.
If an error is returned from the ATPS Query, the document states that the
Verifier SHOULD stop processing and defer the message for later
processing.  This establishes an obvious denial of service vector, but
that may be an acceptable tradeoff in some environments. A feature, as it
were.

However, DKIM "deliberately makes no binding between the DNS domain of the
signer and any other identity found in the message" (Section 1).  I can
envision environment where the message would be accepted by the Verifier,
even without the ATPS signature tag.  In this case, we are deferring an
acceptable message because additional information *might* be available.

That seems odd to me.  Is there any reason a ATPS aware verifier couldn't
process the message and either (a) accept or (b) defer until the ATPS
query succeeds?

At a minimum, I think a brief addition to the security considerations is
in order...

Thanks,

Tim Polk