[ietf-dkim] New Issue: Base: Upgrade indication and
protection against downgrade attacks
eric+dkim at sendmail.org
Wed Feb 15 12:05:56 PST 2006
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
--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
> The IESG will get more and more strict about allowing even SHA-1
> be used, esp. where they don't see a backwards compatibility
> In those cases, I expect they'll want to see SHA-256 used. An
> 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
> but are perhaps better considered to be "strong", "dodgy" or
> at a given moment in time. There should be no reason to use a
> broken algorithm. Dodgy ones (like SHA-1 is now) should only be
> for backwards compatibility. There may be more than one "strong"
> 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
> depending on the details of the attack. With "standard" (i.e.
> 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
> worthwhile including a "U=" attribute, or something, to help
> verifiers handle good signatures.
> - If you sign anything with a really weak algorithm, and the
> can easily generate >1 collision, then the attacker can probably
> create many many different signed messages, perhaps giving rise
> other threats.
> - Lastly, DKIM needs to plan for sha-1 being retired (2010) and
> for sha-256 being superseded by some new NIST-competition-winning
> algorithm in the next 5+ years. So even if we start now with
> sha-256", all of the above is still an issue down the road.
More information about the ietf-dkim