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

Jim Fenton <fenton(_at_)cisco(_dot_)com> writes:

> Eric Rescorla wrote:
> > 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.
> >   
> Hopefully, the presence of a *valid* message signature will be the
> input.  I know you meant this, but there has been discussion as to
> whether non-verification of the signature needs to be included in the
> threats document.
Doh. I meant to write this, but, well, failed.


> > 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.
> >   
> The "figuring out" of which algorithm to use is the central problem
> here.  There just isn't a good way to do it, which is why my text
> suggested the use of two signatures.  The verifier only needs to verify
> one of them, and can decide which hash algorithm to use for the
> verification early in the receipt of the message.  I'm less concerned
> with burdening signers than verifiers.
Certainly, I agree that when transitioning from algorithm A
to algorithm B you need to temporarily sign with both A and B.

The question is to what extent we are transitioning from A
to B. E.g., if we do anything to break existing signatures,
then there's less point in running SHA-1 in parallel since
the signatures won't work anyway and we can just tell people
to deploy SHA-256 verification with the new canonicalization
or whatever.

That said, why are you less concerned with signers than verifiers?
RSA signatures are much faster to verify than generate (about 20x)
so even messages destined for a fair number of people tend to
burden the signer more. And, of course, the verification load is
likely to be more spread out....

-Ekr



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