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

[Vishwas Manral <[e-mail]>]

Hi Pasi,

Thanks a lot for clarifying this further. I will probably try to meet
you if I can make it to the IETF this time over.

Thanks again,
Vishwas

On Tue, Mar 10, 2009 at 12:27 AM,  <[e-mail]> wrote:
> 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
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>