Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements

[<[e-mail]>]

Folks,

Some folks have asked us off-list if this is a new normative IETF
Security Area policy about cryptographic algorithms, and if it is, why
it comes from the area directors instead of, say, SAAG (IETF's
Security Area Advisory Group) or CFRG (IRTF's Crypto Forum Research
Group).

So, to clarify: this is *not* an IETF security area policy; this was
our (Pasi's and Tim's) personal advice to a specific question whether
adding HMAC-SHA1 support to routing protocols that currently only
support MD5-based MACs makes sense or is waste of time (either because
MD5 is good enough for MACs, or because SHA1-based MACs are not good
enough).

Our opinion is a qualified "yes": it's better to get rid of MD5, and
adding support for e.g. HMAC-SHA1 (which we think will be OK for long
time) makes sense *if* at the same time we can do other improvements.
These could include taking a look at the algorithm agility parts of
the protocols (so that adding new MACs in the future will be less
painful, and making sure we can support non-hash-based MACs), making
sure we can do key rollovers without tearing down sessions, improving
MAC coverage, improving replay protection, and so on.

Most of these benefits are not specifically about HMAC-SHA1, and
adding support for some other good MAC could be done instead.  The
IETF does not have any official policy on what MACs are good and what
are not, but going forward, we'd recommend considering non-hash based
MACs, too (so phrasing the situation as MD5 vs. SHA1 is not really
accurate if the protocols really need a MAC, not a hash).

On the other hand, in any given protocol the use of MD5 might not be
currently the weakest link. And if your secret key is something
network administrators can easily remember and type in (as opposed to
copy-pasting from somewhere), it's probably also trivial to discover
by brute force. So when considering adding features to routing
protocols, new hash or MAC algorithms may not necessarily be the
highest priority.

For those who would be interested in having a more comprehensive
IETF-wide policy about hash algorithms, some folks at CFRG are
currently thinking about writing something (perhaps an update to RFC
4270 or something else). Interested folks might want to contact the
CFRG chairs and exchange ideas at IETF74.

Best regards,
Pasi & Tim

> -----Original Message-----
> From: Vishwas Manral <[e-mail]>
> Sent: Mon, 23 Feb 2009 20:09:05 -0800
> To: opsec wg mailing list <[e-mail]>
> Sent: 24 February, 2009 19:12
> Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements
>
>
> Hi folks,
>
> We now have got some clear guidance regarding this document from the
> Security AD's regarding the cryptographic algorithms (Joel has been
> privy to those mails). The guidance seems to second what Hugo and
> other cryptographers have been stating all along. The crux of what
> has been said is:
>
> MD5 should not be used for crypto purposes. SHA-1 though stronger is
> also vulnerable. HMAC-MD5 though not yet vulnerable looks highly
> suspect and should not be reccomended. HMAC-SHA-1 for now looks ok
> and can be reccomended. Goinf forward we should try to reccomend the
> SHA-2 family of protocols.
>
> With these clear guidances matching what we have in our documents, I
> would like to ask the working group to look into this document
> further. We can then look at getting this as a WG document.
>
> Thanks,
> Vishwas