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

[Murray S. Kucherawy]

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of McDowell, Brett
> Sent: Tuesday, January 11, 2011 2:33 PM
> To: ietf-dkim at mipassoc.org WG
> Subject: [ietf-dkim] RFC4871 interoperability conflict over "h= " tag
> 
> (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.

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