Subject: Re: [ietf-dkim] [dkim-ops] key validation question

From: SM <[email-masked]>
Date: Mon, 11 Apr 2011 11:59:10 -0700

Hi Tony,

[I suggest following up on the DKIM WG mailing list]

At 08:07 11-04-2011, Tony Hansen wrote:
>The MUSTs *are* redundant with section 3.3's first paragraph. However,
>it's still important.
>
>If this section were rewritten, I'd suggest something like this:
>
>     h=  Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
>         allowing all algorithms).  A colon-separated list of hash
>         algorithms that might be used.
>
>         As stated in section 3.3, Signers and Verifiers MUST
>         support the "sha256" hash algorithm, and Verifiers MUST also support
>         the "sha1" hash algorithm. Which algorithms are listed
>         in h= is an operational choice by the sender.

You are restating a MUST. :-)  I agree that it is important.  The 
problem here is that it still leads to various interpretations due to 
the keywords.

I'll try rewriting the text in Section 3.6.1:

     h=  Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
         allowing all algorithms).  A colon-separated list of hash
         algorithms that might be used.  Unrecognized hash algorithms
        MUST be ignored.

         Please refer to Section 3.3 for a discussion of the hash algorithms
         implemented by Signers and Verifiers. Which algorithms are listed
         in h= is an operational choice made by the sender.

I kept the MUST in the first paragraph as it is a requirement for 
implementations.

Regards,
-sm 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 11 Apr 2011 15:34:25 -0400

>         in h= is an operational choice made by the sender.

Mr Nit Picker suggests:

         Refer to Section 3.3 for a discussion of the hash algorithms
         implemented by Signers and Verifiers. The algorithms listed
         in h= in each record is an operational choice made by the sender.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Apr 2011 14:55:26 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Hansen
> Sent: Monday, April 11, 2011 2:40 PM
> Cc: [email-masked]; IETF DKIM WG
> Subject: Re: [dkim-ops] [ietf-dkim] key validation question
> 
> >> Mr Nit Picker suggests:
> >>
> > Further nit-picking:
> > "...The list of algorithms included in an h= tag is an operational
> choice made by the sender."
> >
> > ("algorithms" ... "is" doesn't match)
> 
> Wrong noun. "list" ... "is" does match.

I don't see "list" in his text, I see "listed", which is not a noun, it's a verb.  :-)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Apr 2011 13:53:30 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Monday, April 11, 2011 12:34 PM
> To: SM
> Subject: Re: [ietf-dkim] [dkim-ops] key validation question
> 
> Mr Nit Picker suggests:
> 

Further nit-picking:

"...The list of algorithms included in an h= tag is an operational choice made by the sender."

Alternately:

"...The set of algorithms listed..."

---

From: Tony Hansen <[email-masked]>
Date: Mon, 11 Apr 2011 17:39:58 -0400

> "...The set of algorithms listed..."

It would still be an "is".

     Tony Hansen

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Apr 2011 01:59:30 -0400

SM wrote:

>          algorithms that might be used.  Unrecognized hash 
>          algorithms MUST be ignored.
> 
>          Please refer to Section 3.3 for a discussion of the hash
>          algorithms implemented by Signers and Verifiers. Which 
>          algorithms are listed in h= is an operational choice 
>          made by the sender.
> 

I have some related concerns here:

   1) Implementations only expect SHA1 or SHA256
   2) sha1 discovery issues with h=
   3) Text does not address misreading of the spec.

While I think it is implied domain signing should be done with a 
verifier supported hash, the OP post highlighted other things other 
than perhaps a misreading of the spec.

First, there are standard implementations only expecting SHA1 or SHA256.

Second, outside not using h= and expecting the default, there is a 
fine distinction for the motivations to use h= in the first place:

   1) to declare allowable methods,
   2) to declare additional non-standard methods, and
   3) to exclude methods that are not expected to be used.

The common motivation is to enhance security, so if SHA1 discovery is 
a concern, will a domain hash policy declaration of:

     h=rsa-sha256

close SHA1 potential exploits to expose to verifiers that SHA1 based 
signatures are not allowable?

Since there are implementations who will read it just that way and 
fail the verification when a=rsa-sha1 is used for signing, the domain 
is protected by exposing a non-sha1 hash method is used.

But the domain must not lie, which was one of the OP's concern, so I 
think additional text to require the signer to use one of the h= 
specified.

Overall, my suggestion for the text would be something like:

    h=  A colon-separated list of hash algorithms that might be used
        as acceptable hash algorithms. (plain-text; OPTIONAL,
        defaults to allowing only standard registered algorithms).

        When signing mail, the signer MUST use one of the h= methods
        explicitly specified or implicitly using one the default
        standard registered hash algorithms.

        Verifiers not recognizing a hash algorithm or does not
        match a= value MUST invalidate the signature.

Above is how the implementations behave.

Obviously, in general we don't want to expose sensitive discovery 
information that can exploited, but the motivation to use h= in the 
first place is to do just that: an explicit domain policy security 
semantic to exclude insecure exploitable hash methods.

The default continues to keep the door open for SHA1 exploits for 
DKIM, but it is still desirable to get maximum support.  The day 
SHA256 offers wider support, domains can then use h=sha256 to increase 
security.

-- 
HLS

---

From: SM <[email-masked]>
Date: Mon, 11 Apr 2011 23:44:07 -0700

Hi Hector,

I don't feel strongly about the change.

At 22:59 11-04-2011, Hector Santos wrote:
>think additional text to require the signer to use one of the h= specified.

Adding text in RFCs to prevent lies doesn't usually solve problems. :-)

>        match a= value MUST invalidate the signature.

The key in the text proposed earlier is "operational choice" (see 
what Tony suggested).  It is a fix that does not introduce any 
requirements.  The text proposed earlier takes into account what is 
stated in other sections of draft-ietf-dkim-rfc4871bis-05.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Apr 2011 03:56:44 -0400

> Adding text in RFCs to prevent lies doesn't usually solve problems. :-)

Sure, but that is what h= attempts to trap using another level of 
authenticity requirements. We can categorized that scenario many ways 
but its simply about the domain trying to exclude an method a "bad 
guy" can use fraudulently.

> The key in the text proposed earlier is "operational choice" (see what 
> Tony suggested).  It is a fix that does not introduce any requirements.  
> The text proposed earlier takes into account what is stated in other 
> sections of draft-ietf-dkim-rfc4871bis-05.

The point in my text is to spell it out.  Yes, its an operational 
choice, but one that does come with a non-written technical 
requirement. If you specified h=, you are expected to use one of the 
methods listed for signing. Otherwise, current verifiers will see you 
as a "liar" (or bad guy mail) when using something else. :)

-- 
HLS

---

From: Paul Midgen <[email-masked]>
Date: Wed, 27 Apr 2011 02:33:47 +0000

Closing the loop (well, for our question, anyway...): thanks all for the feedback & discussion, based on that and the language in draft-ietf-dkim-rfc4871bis-07, we're going to fix signature validation when we update the inbound MTAs late summer.

Regards,
Paul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Tuesday, April 12, 2011 12:57 AM
To: SM
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] [dkim-ops] key validation question

> Adding text in RFCs to prevent lies doesn't usually solve problems. 

Sure, but that is what h= attempts to trap using another level of authenticity requirements. We can categorized that scenario many ways but its simply about the domain trying to exclude an method a "bad guy" can use fraudulently.

-- 
HLS