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.
Hi Paul, welcome to the list and I personally like to shout
"Its about time!"
Microsoft active support for DKIM especially with policy support will
help DKIM.
I wish to provide some insights about the hash methods as this was
something that inspired the Verifier Discovery idea as described in
the I-D draft proposal DSAP (DKIM Signature Authorization Protocol).
http://tools.ietf.org/html/draft-santos-dkim-dsap-00
I believe section 4.4 provides a background related to the
implementation concerns you expressed regarding hashing SHA1 vs SHA256
methods.
Overall, when the SHA1 security publications surfaced and SHA256
become a new DKIM consideration, there were two principles motivations
to update the DKIM specification design guidelines that would promote
high strength and also provide maximum (verifier) support.
It would of been very simple to just say:
All New Signers MUST use SHA256.
All New Verifiers MUST support SHA1 and SHA256.
But there was one major show stopper. At that time, Windows XP and if
I recall also non-server versions of Windows 2000 & 2003 lacked
support for SHA256 in the OS Crypto API (CAPI) library.
So WIN32 DKIM implementations using CAPI under these OSes would not be
able to verify SHA256 only signatures. There was also active
discussions regarding MUA clients using DKIM add-ons to help cover the
mail hosting market that have yet to support DKIM. Since Windows
clients was a major market that could not be ignored, higher strength
SHA256 enforcement did not come with maximum support.
But we recognized this would be a short term issue, so it would be a
good long term idea to promote SHA256 as the default in the new specs.
However, the short term realistic and prudent implementation would be
to either sign with SHA1 or both by creating two signatures; one
hashed with SHA256 and one hashed with SHA1. Since the DKIM specs for
verification requires at least one valid signature, a high strength,
maximum support need was possible. In the long term, as DKIM verifiers
are upgraded to support SHA256, the signer can stop creating two
signatures.
At first, as I recall, Microsoft was hesitant to update XP and
attempted to leverage the new security issue to encourage migrating
from XP. But eventually, it was added via service packs and since XP
is no longer officially supported today, I will venture signing with
only SHA256 has a higher maximum support.
That said, it appears to me that many sites just use SHA1. We use SHA1
as a default in our mail product DKIM implementation. I think SHA1 is
sufficient for DKIM mail authenticity purposes and any security
exploit concerns using SHA1 a theoretical academic exercise.
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?
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.
From my perspective, I think your p.s. (support for POLICY) is
important here as it shows a positive motivation to use signature
declaration violations for DKIM mail dissemination ideas.
I think it is the right path for DKIM; a path that first filters DKIM
non-compliance and protocol inconsistencies and when the eyes are
dotted and tees crossed (signature is valid), uses reputation to
evaluate the trust of the signer responsible for valid DKIM signature.
The realistic issue is that violations can occur for many reason
including those with no malicious intent. Hence, there is a low
confidence it can be used for filtering with low false positives.
My view is to allow the author domain to make that decision using
signing practice policy semantics and the principle reason is that we
are no longer dealing with legacy mail decisions which are almost
impossible to reliably deal with but one that raises the bar using new
DKIM mail expectations that can be leveraged.
The highest payoff DKIM offers is the expectation violation that a
message is always signed but it it not.
And not just signed but properly signed which is what I believe your
question is related to because under DKIM an invalid signature has an
equal status as no signature ever being present in the message.
I am just saying all this because you are focused on one possible
protocol inconsistency or violation and as others already stated, in
this case, it appears to be more about an ambiguous understanding of
the specs for hashing methods and that is really not your fault.
But if you begin to use the same principle for well understood
protocol violations, I am total agreement and no one should not feel
silly to think in these terms.
DKIM is (still) new. The only silliness is when its incorrectly
deployed and we use this as a reason for relaxing the protocol opening
the door for bad guys to exploit. If we do this, then we are just
repeating the problems in SMTP the new augmented technologies such as
DKIM attempts to correct.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops