Re: [secdir] Secdir review of draft-kucherawy-fkim-atps

["Polk, William T." <[e-mail]>]

[Sorry for the multiple emails, fat fingered the tools address!]

On 1/3/12 4:43 PM, "Polk, William T." <[e-mail]> wrote:

>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
>
>
>
>
>