On 4/8/2011 5:29 PM, Paul Midgen wrote:
Hi folks,
I'm new to the list - as an introduction, I work on inbound delivery&
anti-spam for Hotmail and was responsible for our DKIM implementation late
last year. I have an operational question regarding key validation; having
scanned the archives and not finding an answer - here goes.
Regarding the following portions of sections 3.3 and 6.1.2:
3.3: The rsa-sha256 algorithm is the default if no algorithm is specified.
Verifiers MUST
implement both rsa-sha1 and rsa-sha256. Signers MUST implement and SHOULD sign
using rsa-sha256.
6.1.2: If the "h=" tag exists in the public key record and the hash algorithm
implied by
the a= tag in the DKIM-Signature header field is not included in the contents
of the "h="
tag, the verifier MUST ignore the key record and return PERMFAIL
(inappropriate hash algorithm).
We have chosen a literal, perhaps rigid, interpretation that the key record
must fail validation if it implies lack of support for sha256, e.g. contains
"h=sha1;".
The value of h= does *not* indicate what is *implemented* by the signer
-- it *only* indicates what is currently being *used* to sign with.
Nowhere does the spec say that h= indicates what has been implemented by
the signer.
That said, it's reasonable for a signer to read the same sections and believe
it perfectly okay to implement but not advertise support for sha256. So we
have two problems:
1. If the signer is using sha1, we have no way of knowing they implement
sha256 regardless of whether they advertise it. They could lie.
2. DKIM is made no more or less secure by the inclusion of ":sha256;" in the
key record, so frankly it seems kind of silly to insist on someone inserting
it into their record just so they appear RFC compliant.
In an academic sense, I require signers to appear (and hopefully *be*) RFC
compliant because it's important - like stopping at a red light even if
nobody else is around. Practically, operationally, I feel like I'm being
silly.
So: do I relax the key validation routine or stay true to the written word?
The h= value is an operational indication of what signing algorithms are
currently being used by the signer, so that you can preemptively
disallow any signatures that are not in that list. It has *nothing* to
do with the list of algorithms that are implemented by the signer.
Look at it from the other way around -- an implementation might
implement both sha1 and sha256, but only advertise with h= that it will
only ever sign with sha256. This may very well be the case in a few more
years when sha1 is categorically declared as being broken. At that
hypothetical point in time in the future, implementations may very well
still implement sha1, but I for one would look askance at any dns key
record that said that sha1 was still being used. In fact, at that time,
having both sha1 and sha256 listed in the dns key record would be a
serious security hole, allowing someone to spoof a signature using sha1.
You've misread the specs and are treading on dangerous grounds.
Tony Hansen
tony(_at_)att(_dot_)com
Thanks.
-Paul
p.s. Yes, this is a real world scenario, and I am currently rejecting the
sender's mail as they've chosen to publish ADSP-DISCARDABLE.
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops