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 22:55:23
-----Original Message-----
From: SM [mailto:sm(_at_)resistor(_dot_)net]
Sent: Tuesday, May 25, 2010 5:21 PM
To: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf