ietf-dkim
[Top] [All Lists]

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

2006-02-27 16:00:10
The difference between 1 and 2 is only marketing but marketing is
critical. I still get people obsessing about the 'overhead' of XML in
the most ridiculous circumstances you can imagine (like a 1kb/sec
control channel to a 1Mb/sec live data channel).

I think we should go with (2).


Given the amount of thrashing we have here I think we need a procedure
for issue closure. I don't think that there is anyone who is in serious
disagreement with option 2:

 2. Require SHA-1 and SHA-256 verification support and recommend
    (require?) signatures with SHA-256.



-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Eric Rescorla
Sent: Monday, February 27, 2006 5:24 PM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: DKIM IETF WG
Subject: Re: [ietf-dkim] Core algorithm support/use, draft text v2

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



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