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: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla
> Sent: Monday, February 27, 2006 5:24 PM
> To: [EMAIL PROTECTED]
> Cc: DKIM IETF WG
> Subject: Re: [ietf-dkim] Core algorithm support/use, draft text v2
>
> Dave Crocker <[EMAIL PROTECTED]> 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
