[ietf-dkim] Core algorithm support/use, draft text v2
ekr at networkresonance.com
Mon Feb 27 14:24:26 PST 2006
Dave Crocker <dhc at dcrocker.net> writes:
> My own opinion is that double signing is overkill -- and maybe
> misleading -- for this application. As I understand things, SHA-1
> is, in fact, valid for use today. At the least, if sha-1 gives
> acceptable security, then sha-256 isn't needed. If it does NOT give
> acceptable security, then it
> should not be used.
> So double signing gives compatibility without better strength, but
> with lots more overhead. In other words, I do not see the upside of
> the double signature.
I tend to agree with Dave here.
That said, I think it's important to examine the security
requirements. As I understand it, the major objective here is to use
the presence or absence of the message signature as an input to a
filtering process. Accordingly, unlike with S/MIME, it's not really
critical that people stop relying on a weakened hash algorithm as long
as the cost to forge a signature with that algorithm is
Even if a collision attack is useful for attacking DKIM,
the cost to forge a SHA-1 signature would be quite high (2^61 as of
now), so the probability that a signed message is valid would remain
quite high. Given that the theory seems to be to treat an invalid signature
as nonexistent, this seems like an appropriate treatment to give an
invalid hash algorithm as well. So, I don't see a problem with letting
senders figure out which algorithm to use based on the likely
level of recipient deployment.
It seems to me that the key requirement here is that if/when senders
start moving to some new algorithm, that we be able to have a
smooth transition. That requires two things:
1. That recipients handle multiple signatures correctly. I.e.,
that signatures with unacceptable algorithms are skipped
rather than creating an error if there is a valid signature.
2. That support for verifying that new algorithm be available
broadly prior to senders starting to use it exclusively.
Given that, I think that we should either:
1. Require SHA-1 and SHA-256 verification support and recommend
signatures with SHA-1.
2. Require SHA-1 and SHA-256 verification support and recommend
(require?) signatures with SHA-256.
3. Require SHA-256 support and forbid SHA-1 in both generation
Option (3) seems like overkill. I don't have a strong opinion
between (1) and (2), but probably lean towards (2) on the grounds
that it's better to use something that we don't know has problems,
even probably irrelevant ones.
More information about the ietf-dkim