[ietf-dkim] RFC4871 interoperability conflict over "h= " tag
Murray S. Kucherawy
msk at cloudmark.com
Tue Jan 11 15:30:45 PST 2011
> -----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.
More information about the ietf-dkim