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@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf