> -----Original Message----- > From: SM [mailto:sm@xxxxxxxxxxxx] > Sent: Tuesday, May 25, 2010 5:21 PM > To: ietf@xxxxxxxx > Cc: Murray S. Kucherawy > Subject: Re: Last Call: draft-kucherawy-authres-header-b > (Authentication-Results Registration For Differentiating Among > Cryptographic Results) to Proposed Standard Hi SM, > I read this draft and I support it as I am using it in an > implementation. Thanks for the review! > 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. I'd be fine with that if the IESG or general consensus feels that's appropriate. RFC5451 included support for DomainKeys in observance of its wide deployment even though it's got "Historic" status so I also included it here, but I don't have particularly strong feelings about continuing to do so. > "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? One would have to register another mechanism for making an unambiguous reference if it's reasonably possible that a collision can occur. > 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. It still could, if the signature product is somehow shorter than eight characters. I'm not sure I understand what's gained by removing the second part. > 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)? I could be explicit there, but I thought it was clear enough that those are the two mechanisms being referenced. I don't mind naming them here though if it improves clarity. > 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. That's true, the attack creates the appearance of a false negative while it's (in theory) impossible to create a false positive. Knowing that, one could perhaps disregard it. The specification could spell that out, but it's useful I think to point out that the attack at least creates a confusing result. > As an editorial nit, Acknowledgements is generally in a section > instead of an Appendix. I see that in some published RFCs, but I didn't see how to create a non-appendix section after the appendices using xml2rfc. -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf