ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Core algorithm support/use, draft text v2

2006-02-27 15:27:41
Dave Crocker <dhc(_at_)dcrocker(_dot_)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
substantial.

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
   and verification.

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.

-Ekr            










_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>