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

["Vishwas Manral" <[e-mail]>]

Hi Phillip,

I agree we probably could have some document talking about generic
recommendations like those you suggest. However I would feel every
application may have its own set of requirements which may overlap but
not necessarily be the same. Not all applications require the same
level of security.

That said I would think the TCP-AO draft should follow the
recommendations of RFC4835 like Eric mentioned earlier.

Thanks,
Vishwas

2008/2/14 Hallam-Baker, Phillip <[e-mail]>:
>
>
>
> 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: [e-mail] on behalf of Eric Rescorla
> Sent: Fri 04/01/2008 7:44 PM
> To: Brian Weis
> Cc: [e-mail]
> 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
> [e-mail]
> http://mailman.mit.edu/mailman/listinfo/saag
>
> _______________________________________________
>  saag mailing list
>  [e-mail]
>  http://mailman.mit.edu/mailman/listinfo/saag
>
>