Subject: Generic BFD Crypto

From: Vishwas Manral <[email-masked]>
Date: Mon, 26 Jan 2009 20:31:08 -0800

Hi folks,

Please see below the discussion with the Security-AD's regarding the
crypto algorithms to support and recommend. We have written a draft to
satisfy some part of the same. Do have a look and let us know any
comments you may have regarding the same?

http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-00

Thanks,
Vishwas

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, Jan 26, 2009 at 5:28 AM
Subject: RE: MD5 Vs SHA-1 direction
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]

Hi Vishwas,

And apologies that replying to your email took so long! We wanted to
consult with some hash function experts, and our deliberations took
longer than we had expected.

Anyway, here's our advice currently:

- For HMAC, there are no practical attacks (yet) for HMAC-MD5 or
HMAC-SHA1. We agree with Hugo Krawczyk that HMAC-MD5 is starting to
look suspicious, and should be replaced (before attacks become
practical). We believe that HMAC-SHA1 provides an acceptable level of
security for most applications for the time being, and is a big
improvement over HMAC-MD5. For most applications HMAC-SHA1 is a good
choice as the mandatory to implement algorithm.  However, we're
encouraging folks to design for algorithm agility, and also support
other MAC algorithms in addition to HMAC-SHA1 (such as AES-CMAC).

- Some routing area protocols use MD5/SHA-1 based MACs that are not
HMAC -- for example, the "secret-suffix/append-only" construction in
OSPFv2 and current BFD drafts.

These constructions have known to be problematic for more than a
decade, even when used with a perfectly good hash function.  As far as
we know, using them with broken hash functions (like MD5) has not been
thoroughly analyzed yet, but the likelihood of practical attacks is
much higher than for HMAC-MD5. We recommend replacing these with
HMAC-SHA1 and/or AES-CMAC (and at the same time, considering algorithm
agility so that other MACs can be easily added in the future).

- For anything involving public-key signatures, neither MD5 or SHA-1
is a good idea.  MD5 has practical attacks, and SHA-1 is showing signs
of weakness.  The U.S. Government is phasing out SHA-1 for most
public-key signatures by the end of next year.  For the time being, we
recommend specifying SHA-256 as the mandatory to implement algorithm.
Even though other hash functions might be coming in the future (e.g.
from the NIST hash competition), SHA-256 appears to be a good choice
today (and has a safety margin that should make attacks impractical
for a long time). As with HMAC, designing for algorithm agility is
important step in the right direction.

- Hash functions might also be used in other contexts than public-key
signatures and MACs/PRFs (although that's much rarer, and does not
occur in every protocol). It's possible that some of these places
don't actually need a cryptographically secure hash function (and
using MD5, or even CRC32, would be OK), but doing the analysis for
each case is a lot of work. We believe that for most cases, the
simplest (least work) solution is to use a good hash function with a
sufficient safety margin, like SHA-256. (Note that while we believe
HMAC-SHA1 continues to be OK, we do not recommend using SHA-1 for
anything that assumes collision resistance.)

Best regards,
Pasi & Tim