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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, (continued)
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Jim Fenton
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Eric Rescorla
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Jim Fenton
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Eric Rescorla
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Jim Fenton
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Mark Delany
- Re: [ietf-dkim] Core algorithm support/use, draft text v2, Douglas Otis
RE: [ietf-dkim] Core algorithm support/use, draft text v2, Hallam-Baker, Phillip
RE: [ietf-dkim] Core algorithm support/use, draft text v2, Hallam-Baker, Phillip
RE: [ietf-dkim] Core algorithm support/use, draft text v2,
Hallam-Baker, Phillip <=
RE: [ietf-dkim] Core algorithm support/use, draft text v2, Hallam-Baker, Phillip
|
Previous by Date: |
Re: [ietf-dkim] Core algorithm support/use, draft text v2, Eric Rescorla |
Next by Date: |
Re: [ietf-dkim] Core algorithm support/use, draft text v2, Jim Fenton |
Previous by Thread: |
RE: [ietf-dkim] Core algorithm support/use, draft text v2, Hallam-Baker, Phillip |
Next by Thread: |
RE: [ietf-dkim] Core algorithm support/use, draft text v2, Hallam-Baker, Phillip |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|