ietf
[Top] [All Lists]

Re: Last Call: draft-kucherawy-authres-header-b (Authentication-Results Registration For Differentiating Among Cryptographic Results) to Proposed Standard

2010-05-25 19:47:17
At 13:26 03-05-10, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:

- 'Authentication-Results Registration For Differentiating Among
   Cryptographic Results '
   <draft-kucherawy-authres-header-b-01.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2010-05-31. Exceptionally,

I read this draft and I support it as I am using it in an implementation.

In Section 4:

  "The value associated with this item in the header field MUST be at
   least the first eight characters of the digital  signature (the
   "b=" tag from a DKIM-Signature or DomainKey-Signature  header field)
   for which a result is being relayed, and MUST be long  enough to be
   unique among the results being reported."

As DomainKeys (RFC 4870) is historic since the last three years, it would be better to drop it from this specification.

  "Where the signature of a future method is fewer than eight
   characters, the entire signature MUST be included."

Would it be possible to ensure the unambiguous association then?

Going over the MUSTs, "the value associated with this item in the header field MUST be at least the first eight characters of the digital signature". We then have "Where the signature of a future method is fewer than eight characters, the entire signature MUST be included".

I suggest keeping the first requirement for at least eight characters. A future method with less than eight characters cannot use "header.b" then.

In Section 6.2:

   "An attacker could copy a valid signature and add it to a message in
   transit, modifying some portion of it.  This could cause two results
   to be provided for the same "header.b" value even if the entire "b="
   string is used in an attempt to differentiate the results.  This
   attack would neutralize any benefit given to a "pass" result that
   would have otherwise occurred, possibly impacting the delivery of
   valid messages."

Shouldn't "valid signature" be "valid DKIM-Signature header field" (or DomainKey-Signature header field)? If I understood this section, the aim is to get two identical "header.b values (the first eight characters). One of them (the copied one) would generate a verification failure. That doesn't negate the (pass) result if the focus is on what has been successfully verified.

As an editorial nit, Acknowledgements is generally in a section instead of an Appendix.

Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf