SM wrote:
[I suggest following up on the DKIM WG mailing list]
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.
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html