[ietf-dkim] New Issue: Base: Upgrade indication and protection against downgrade attacks

Eric Allman eric+dkim at sendmail.org
Wed Feb 15 12:05:56 PST 2006


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.farrell at cs.tcd.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.



More information about the ietf-dkim mailing list