Subject: [ietf-dkim] RFC4871 interoperability conflict over "h= " tag

From: "McDowell, Brett" <[email-masked]>
Date: Tue, 11 Jan 2011 15:33:14 -0700

(if this doesn't belong on this list, please let me know)

RFC 4871 states:

> h=  Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
>        allowing all algorithms).  A colon-separated list of hash
>        algorithms that might be used.  Signers and Verifiers MUST
>        support the "sha256" hash algorithm.  Verifiers MUST also support
>        the "sha1" hash algorithm.

We have a DKIM-signed mail stream that is "passing" with Receiver1 but failing with Receiver2 and it's Receiver2 who has a "new" interpretation of the requirement above.  Here are the two interpretations, please let me know which is generally considered correct (of if both are wrong):

Interpretation #1:  The sender must support both, but doesn't need to use both.  It could be h=sha1, h=sha256, h=sha1:sha256, or h=*.  The receiver however MUST support either.  Therefore the receiver should be not fail verification just because the explicit tag in the DNS record says "h=sha1" instead of the "h=sha1:sha256" which is expected.

Interpretation #2:  The sender must support both, which means the sender must either not have an h= tag in the DNS record (defaulting to h=sha1:sha256) or it must explicitly list "h=sha1:sha256" and therefore the sender should adjust their public key records vs. the receiver adjusting their infrastructure to verify "h=sha1" (btw, this is for messages that contain "a=rsa-sha1" in the DKIM-Signature header).

I may have provided both too much and too little information, but this is the interoperability problem we are facing at the moment.

Comments?

Many thanks!

-- Brett

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Jan 2011 15:30:45 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of McDowell, Brett
> Sent: Tuesday, January 11, 2011 2:33 PM
> To: [email-masked] WG
> Subject: [ietf-dkim] RFC4871 interoperability conflict over "h= " tag
> 

The "a=" value indicates a signature generation algorithm, and the definition of that algorithm indicates which hash (message digest) method was used as part of that algorithm.  Thus, in essence, the "a=" in the message and the "h=" in the key have to line up for verification to complete.

For example, if you send me a message signed with "a=rsa-sha1", then when I retrieve your key, I expect to see no "h=" value there, or a value that includes "sha1".

> Interpretation #1:  The sender must support both, but doesn't need to
> use both.  It could be h=sha1, h=sha256, h=sha1:sha256, or h=*.  The
> receiver however MUST support either.  Therefore the receiver should be
> not fail verification just because the explicit tag in the DNS record
> says "h=sha1" instead of the "h=sha1:sha256" which is expected.

You're saying a bunch of different things here:

"The sender must support both, but doesn't need to use both."  True.

"It could be h=sha1, h=sha256, h=sha1:sha256, or h=*."  True except the last, as "*" isn't valid by that tag's ABNF.

"The receiver however MUST support either."  True, inasmuch as "either" is a subset of "both". :-)

"Therefore..."  Depends on the signature.  If the record says "h=sha1" but the signature says "a=rsa-sha256", I'd fail it.

> Interpretation #2:  The sender must support both, which means the
> sender must either not have an h= tag in the DNS record (defaulting to
> h=sha1:sha256) or it must explicitly list "h=sha1:sha256" and therefore
> the sender should adjust their public key records vs. the receiver
> adjusting their infrastructure to verify "h=sha1" (btw, this is for
> messages that contain "a=rsa-sha1" in the DKIM-Signature header).

I think you're mixing implementation with policy.  The "h=" tag in a key record is an expression of policy that this key can only be used with the specified hashes.  It is not a statement of what the signer implements.

-MSK

---

From: SM <[email-masked]>
Date: Tue, 11 Jan 2011 15:42:39 -0800

Hi Brett,
At 14:33 11-01-11, McDowell, Brett wrote:
>We have a DKIM-signed mail stream that is "passing" with Receiver1 
>but failing with Receiver2 and it's Receiver2 who has a "new" 
>interpretation of the requirement above.  Here are the two 
>interpretations, please let me know which is generally considered 
>correct (of if both are wrong):

You can DKIM sign with SHA1 or SHA256 as the verifier supports 
both.  Your DKIM signing implementation has to implement SHA256.

If the DKIM verifier sees a DKIM-Signature using SHA1 while the DKIM 
signer publishes h=
sha256, see Section 6.1.2, step 7.

Regards,
-sm

---

From: "McDowell, Brett" <[email-masked]>
Date: Wed, 12 Jan 2011 11:39:07 -0700

Thank you both for your input.

To summarize... a receiver should not fail a message simply because the sender has "h=sha1" in their DNS and "a=rsa-sha1" on their signatures, even though that particular configuration isn't exactly expected by an acutely accurate reader of the RFC.

Yes?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Jan 2011 11:24:57 -0800

> From: McDowell, Brett [mailto:[email-masked]]
> Sent: Wednesday, January 12, 2011 10:39 AM
> To: Murray S. Kucherawy
> Cc: [email-masked] WG
> Subject: Re: [ietf-dkim] RFC4871 interoperability conflict over "h= " tag
> 
> To summarize... a receiver should not fail a message simply because the
> sender has "h=sha1" in their DNS and "a=rsa-sha1" on their signatures,
> even though that particular configuration isn't exactly expected by an
> acutely accurate reader of the RFC.

If an "a=rsa-sha1" message matching a "h=sha1" key fails for reasons other than the usual things that cause a signature to fail (i.e. alteration in transit or mismatched keys), I'd say the verifier is doing something that looks a lot like breakage to me.

---

From: SM <[email-masked]>
Date: Wed, 12 Jan 2011 15:31:09 -0800

Hi Murray,
At 11:24 12-01-11, Murray S. Kucherawy wrote:
>If an "a=rsa-sha1" message matching a "h=sha1" key fails for reasons 
>other than the usual things that cause a signature to fail (i.e. 
>alteration in transit or mismatched keys), I'd say the verifier is 
>doing something that looks a lot like breakage to me.

My reading of Brett's message is that the specification is 
unclear.  There is the following informative note in Section 3.3:

       INFORMATIVE NOTE: Although sha256 is strongly encouraged, some
       senders of low-security messages (such as routine newsletters) may
       prefer to use sha1 because of reduced CPU requirements to compute
       a sha1 hash.  In general, sha256 should always be used whenever
       possible.

You mentioned implementation and policy in a previous message.  The 
first paragraph of Section 3.3 describes the software requirements 
for the DKIM implementation.  The second paragraph describes how the 
software may be used.  I'll use Murray's description and call it 
policy.  The better fit may be "operations" and how to ensure interoperability.

According to Section 4.1.2 of draft-ietf-dkim-implementation-report-05:

   '50.5% of signatures used "rsa-sha1", while the  balance
    used "rsa-sha256".'
If receivers want to reinterpret the requirements, they may see more 
"DKIM failures".

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 12 Jan 2011 16:35:19 -0800

Brett, et al,

On 1/11/2011 2:33 PM, McDowell, Brett wrote:
> I may have provided both too much and too little information, but this is the
> interoperability problem we are facing at the moment.

I think what follows does /not/ contradict anything posted so far, and I think I 
understand the issues I'm about to comment on, but some of the material covers 
details that I always feel pretty tentative about.  So if something doesn't seem 
right about what follows, it well might not be.  On the other hand, this does 
mean I'll be even more pedantic than usual, by way of trying to be extra careful...

Your question appears to run smack into differences between protocol 
"implementation", protocol "use" and security "enforcement".

Implementation:

The specification for hash support says what must be implemented within code 
doing DKIM hashing.  That is, there must be software the implements each 
algorithm.  It does not say that either of them in particular must be used...

In particular a signer is left free to use either and well might choose to use 
only one and never the other.  That's legal.

For such an environment, hence, implementing the other algorithm was a waste of 
time, which leads to the entirely reasonable question of why bother?[1]

The important part of the implementation issue is that a verifier has to be able 
to process messages coming in with either of these hashes.

Use:

The hash spec gives a recommendation about actual use, but leaves the final 
choice to the signer.

Enforcement:

(You didn't specifically say that the h= was for the DNS record, rather than for 
the DKIM-Signature, but that's the only interpretation that makes sense.  I'm 
including this parenthetical text just to make sure.)

Implementation and Use rules are in the protocol spec, not in the DNS record.

The reason for the h= tag in the DNS record is to constrain what hash algorithms 
are permitted for a particular key.  That is, it is a means by which the name 
owner can declare some security rules that the verifier is requested to enforce.

I believe the usual rationale is a concern for some form of down-rev attack.  So 
the owner might want only the stronger hash to be used, but someone might figure 
out a way to use the weaker one for an attack. This becomes important as the 
weaker one becomes nearly useless, with better computing and better attack 
methodology.

Hence, as Murray notes, the verifier takes the a= value and checks for its 
presence in the h= tag, if there is one.  If there is a tag and the hash 
algorithm isn't listed, that should generate a failure.

At any rate, in this context, for the DNS record h= specification, I believe the 
third sentence of the specification should not be present.  It is making a 
declaration about what must be built into the protocol engine for doing hashing. 
  That's not the scope of this segment of the spec.

      I therefore believe that 'Signers and Verifiers MUST support the "sha256" 
hash algorithm. Verifiers MUST also support the "sha1" hash algorithm.' should 
be removed from that segment Section 3.6.1 (Textual Representation.)

      It belongs either in 3.5 (a=) or more probably in Section 3.3 (Algorithms).

So interpretation #1 looks the most in line with what I think the spec calls for 
but I don't see ABNF to permit h=*.  (Or is this one of that typical cases of my 
missing something obvious?)

Interpretation #2 does not frankly make a lot of sense to me, though I guess I 
can imagine the glasses one would need to look through to see things that way. 
Certainly interpretation is not helped by the "support" sentence erroneously 
being in this segment.

There are implications of what must be listed in the h= parameter, but they are 
not properties of h= as much as they are of the algorithm portions of the spec. 
  That is, if only sha1 and sha256 are supported in the standard, then one or 
the other or both are the only standards-based labels that can be in h=. [2]

d/

[1] Mandating "implementation" by a signer (protocol generator): If a protocol 
generator is free to limit themselves to /using/ only a part of the protocol or 
a subset of values, then it makes no sense to mandate that they "implement" a 
part that they won't be using.

     (One of the better examples of this sort of specification "directional" 
sloppiness was for Telnet which declares that telnet is symmetric, with telnet 
options that do not declare that they are intended to be used in one direction 
only.  Because of this, I once had a potential customer require us to 
demonstrate that our CLIENT telnet could receive and process a WILL ECHO option 
request...)

[2] Redundant specification.  My goodness but this is a timely topic.  I happen 
to now notice that the header field a= specification and the DNS record h= field 
have substantial redundancy in their ABNF.  This should be compressed so that 
one uses relevant rules from the other.  (One might even argue for defining 
those in Section 3.3 or perhaps merely citing the relevant registry declarations 
in the IANA Considerations sections.)  In any event, all this redundancy should 
be eliminated.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html