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