[saag] Managing aglorithms RE: TCP-AO MAC algorithms

To tie a number of threads together here I think it would help enormously if we had some sort of cross IETF statement of the set of algorithms that are currently the consensus recommendations for support.

I don't think that there is a lot of disagreement on the important points, e.g. :

* If you are designing an entirely new protocol that requires block encryption specify AES-128 and AES-256 as MUST

* The use of 3DES, HMAC-SHA1, should be avoided in entirely new protocols but is not cause for concern in deployed protocols.

* Use of SHA1 should be avoided except in deployed protocols where there has been careful analysis that demonstrates use in that application is not cause for concern.

* Use of MD5, ciphers with a strength of 56 bits or less should be avoided in almost all circumstances. Use of ciphers with key sizes of 64 bits or less should be discontinued as soon as is practicable.

* If someone wants to specify vanity crypto, give them the necessary URI or OID and tell them to use it at their own discretion.

I don't think we should have this discussion in every individual working group. 

I especially don't want to have to have the discussion on how to use ECC with each individual IETF spec in turn. Or worse have extended discussions over the optimal choice of group etc. so that we end up with different choices across the IETF. If the specifications are well designed we should have all the information necessary to specify how to use algorithms across the board.

As things stand I think we are going to end up with more crypto configurations in IETF protocols than we have crypto people. And that would be a bad thing when there is a pretty strong consensus on preferred algorithms in the field.

________________________________

From: saag-bounces@mit.edu on behalf of Eric Rescorla
Sent: Fri 04/01/2008 7:44 PM
To: Brian Weis
Cc: saag@mit.edu
Subject: Re: [saag] TCP-AO MAC algorithms

At Fri, 4 Jan 2008 15:06:59 -0800,
Brian Weis wrote:
>
>
> On Dec 31, 2007, at 6:06 PM, Eric Rescorla wrote:
>
> > At Tue, 18 Dec 2007 16:23:51 -0800,
> > Brian Weis wrote:
> >>
> >> Greetings,
> >>
> >> The TCPM WG seeks advice from SAAG on which MACs to include as
> >> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp-
> >> auth-opt-00).
> >
> > I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC
> > 4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why
> > TCP-AO should have stricter MTI requirements than we have for
> > our dedicated security protocols?
>
> The rationale is simply that two methods with differing internal 
> constructions implies that the standard is better prepared for the 
> future (if one of the two MACs is perceived to be broken).

Yes, this strikes me as massive overkill, given that typical
MAC constructions are designed with some kind of reduction
to the primitive they are based on. If, for instance, SHA-256
is broken badly enough that it implicates HMAC, it seems
likely that we're going to have so many other cryptographic
problems that the remaining security of TCP-AO will be the
least of our worries.

> >> Two MACs with differing internal constructions are
> >> desired.
> >
> > I don't understand this either. Most modern MACs are constructed from
> > two pieces:
> >
> > - An underlying cryptographic function
> > - A composition operation
> >
> > Thus, for instance, HMAC-SHA1 is constructed by using the HMAC
> > composition operation with SHA-1. In general, the security properties
> > of the composition operations are well understood (often with some
> > kind of reduction proof) where the security properties of the
> > underlying function are unproven. So, while it might make sense
> > to have two different base cryptographic functions (e.g.,
> > SHA-1 and SHA-256), it's not at all clear that it's of that
> > much value to have two different constructions.
>
> Agreed that if two RTI MACs are chosen that the MACs must be 
> significantly different. That's why the proposed set includes one of 
> SHA-1 using HMAC (a Wegman-Carter MAC), and another of AES using CMAC 
> (a cipher block chaining mode intended for authentication).

I'm not sure why you say "agreed". As I said, I don't agree with this.

On the contrary, I don't see much value in using different
constructions. There's no reason to believe there's anything wrong
with HMAC, the issue (to the extent to which there is any) is purely
with the digests used by HMAC. If, for some reason, there is a perceived
need to specify two functions HMAC with two different (potentially
unrelated) digests seems fine.

-Ekr

_______________________________________________
saag mailing list
saag@mit.edu
http://mailman.mit.edu/mailman/listinfo/saag