Re: [ietf-dkim] New Issue: Base: Upgrade indication and protection again

Hi Eric,

I agree that these are separable issues. Dave just followed up on
the sha1/sha256 point - other points I made were algorithm
independent, in particular I find it hard to see how to counter a
downgrade attack when we cannot negotiate and have to stick with
pkcs#1 signatures - but I would agree that the idea is worth
following up.

S.

Eric Allman wrote:
> Stephen,
>
> Although I have no objection to anything you say, I think you are 
> missing the point.  sha1 vs sha256 was just a placeholder; Mark could 
> have said "AlgorithmA" vs "AlgorithmB".  The point is how we can avoid 
> downgrading attacks, not what we should do about the specific sha1 problem.
> eric
>
>
> --On February 15, 2006 12:56:05 PM +0000 Stephen Farrell 
> <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
> > Hi Mark,
> >
> > Just a few additional considerations:-
> >
> > - SHA-1 is now considered to be 2^63 "strong" & that'll only get
> > worse.
> >    The IESG will get more and more strict about allowing even SHA-1
> > to
> >    be used, esp. where they don't see a backwards compatibility
> > problem.
> >    In those cases, I expect they'll want to see SHA-256 used. An
> > issue
> >    for DKIM is whether to include SHA-1 for anything at all, or for
> >    more than compatibility with pre-standards versions.
> >
> > - Algorithms don't necessarily have a fixed, known, order of
> > "strength",
> >    but are perhaps better considered to be "strong", "dodgy" or
> > "broken".
> >    at a given moment in time. There should be no reason to use a
> > known
> >    broken algorithm. Dodgy ones (like SHA-1 is now) should only be
> > used
> >    for backwards compatibility. There may be more than one "strong"
> > at
> >    any given time, e.g. sha-256, sha-512 or perhaps whirlpool, and
> >    perhaps their use will break down not by strength, but say,
> >    geographically, or by industry or whatever.
> >
> > - If an algorithm is dodgy, then an attacker may be able to generate
> >    collisions that remove or modify, any "U=" attribute, or
> > equivalent,
> >    depending on the details of the attack. With "standard" (i.e.
> > pkcs#1)
> >    signing, I don't think we can do much better really and I don't
> >    think we want to get into modifying pkcs#1 here. Even so, it may
> > be
> >    worthwhile including a "U=" attribute, or something, to help
> >    verifiers handle good signatures.
> >
> > - If you sign anything with a really weak algorithm, and the
> > attacker
> >    can easily generate >1 collision, then the attacker can probably
> >    create many many different signed messages, perhaps giving rise
> > to
> >    other threats.
> >
> > - Lastly, DKIM needs to plan for sha-1 being retired (2010) and
> > probably
> >    for sha-256 being superseded by some new NIST-competition-winning
> >    algorithm in the next 5+ years. So even if we start now with
> > "only
> >    sha-256", all of the above is still an issue down the road.
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html