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

From: SM <[email-masked]>
Date: Tue, 25 May 2010 17:20:57 -0700

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
>[email-masked] 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 25 May 2010 20:54:59 -0700

> -----Original Message-----
> From: SM [mailto:[email-masked]]
> Sent: Tuesday, May 25, 2010 5:21 PM
> To: [email-masked]
> 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

Thanks for the review!

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

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

> characters.  A future method with less than eight characters cannot

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.

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

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

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

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 25 May 2010 21:48:08 -0700

On 5/25/2010 8:54 PM, Murray S. Kucherawy wrote:
>> 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.

The goal of pressing to have DomainKeys declared Historic was/is to press for
adoption of DKIM.  That's aided by removing support elsewhere, especially in
/new/ standards.

The removal also makes the authres spec that much simpler.  Simpler is better.

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

I also suggest avoided repeating normative text.

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

Last couple of docs I've worked on have Security, IANA and Acknowledgements as 
the last 3 sections of <middle></middle>.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: SM <[email-masked]>
Date: Tue, 25 May 2010 22:18:34 -0700

Hi Murray,
At 20:54 25-05-10, Murray S. Kucherawy wrote:
>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.

There is a normative reference to RFC 4871 (it obsoletes RFC 4870) 
and an informative reference for RFC 4870.  You can drop the second 
reference then.  Section 5 (registry) would have to be adjusted accordingly.

It made sense for RFC 5451 to include support for DomainKeys as that 
specification was written around the same time as DKIM.  Dropping RFC 
4870 is a way to say "we encourage you to stop using software which 
is no longer maintained". :-)

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

There was a comment about eight bytes a large amount of pseudo-random 
data ( 
http://mipassoc.org/pipermail/mail-vet-discuss/2010q1/000591.html 
).  If the second part is removed, the minimum becomes eight 
characters.  The first MUST mention unique; the second doesn't 
mention "unique".

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

It would be clearer for attackers reading this specification if you 
were explicit. :-)

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

I was thinking of disregarding such data (implementation detail).  I 
agree that the attack could create a confusing result.

>non-appendix section after the appendices using xml2rfc.

<section title="Acknowledgements"> should work.

Regards,
-sm

---

From: Joe Abley <[email-masked]>
Date: Wed, 26 May 2010 19:11:45 +0200

> <section title="Acknowledgements"> should work.

I think you would need to create the section at the back of the <front> section, and not in the <back> section. <section> elements that are children of <back> are rendered in text with appendix-style numbers.

Or just include a note that you would like the section not to be numbered as an appendix, and trust the RFC editor to deal with it in due course :-)

Joe