Subject: [AVT] Re: [saag] The use of AES-192 and AES-256 in Secure RTP

From: David McGrew <[email-masked]>
Date: Thu, 4 May 2006 06:35:06 -0700

Hi Rick,

On May 3, 2006, at 7:18 PM, Rick Porter wrote:

>
> I was surprised to see Suite B appear on someone's radar...
>
> IMO, most aspects of SRTP would not meet the standards for Suite B
> certification. The key exchange seems to be the most blatantly  
> lacking,
> but there are other aspects.

you are right that there is probably no standardized way to provide  
keys to SRTP that would meet the Suite B guidelines.  But this  
doesn't imply that we shouldn't specify a Suite B conformant profile  
for SRTP (since we don't want to create a chicken-or-egg-first?  
situation).  Also, some of the proposed key management methods do  
incorporate or admit FIPS-140/Suite B approved key establishment  
methods (for example, DTLS-SRTP could be used with one of the ECC  
methods currently being drafted for TLS).

> Let me point out that the Suite B link does
> not even mention which mode(s) of AES are acceptable (e.g. counter,  
> cbc,
> ecb, wrap).
>

You're right that Suite B is underspecified, and it would be  
reassuring to get more details about it.  (I prefer "underspecified"  
to "overly narrow" though :-)

> I do not have a strong opinion about whether or not to specify longer
> AES key lengths. However, I would not specify longer key lengths  
> just to
> comply with the Suite B standards--NSA is probably going to require
> deviation from the IETF standard(s) anyway. NSA has its own set of
> requirements (and reasons for them), and they also have a number of
> government contractors who develop products to meet those  
> requirements.

True, but I would rather work with Suite B and try to promote broader  
interoperability.  I think that the big value of Suite B is that it  
will enable interoperability between the high-assurance  
implementations that you mention and commercial standards-based  
implementations.  This is an obvious gain for the high-assurance  
community, and it could also benefit the commercial community.  But  
I'm getting off topic here; Suite B is worth discussing, but the use  
of elliptic curve crypto is the most important topic there, not SRTP  
key sizes ;-)

David

> Cheers,
> Rick

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 8 May 2006 12:33:16 +0200

Hi David, hi Lakshminath,

sorry for the late response to that issue:

> >>2. I would suggest that this draft include AES-based CMAC, so we
> >>can move away from SHA-1 and also use a single crypto primitive for
> >>encryption, and PRF and MAC computation (opinion on your open
> >>question).
> >
> >We think alike :-)  I implemented AES CMAC for SRTP and found that it
> >performs better than HMAC-SHA1 for very short packets (like those for
> >conversational voice over a WAN) but not long packets (like video).
> >It also has some other advantages.  But OTOH there is a cost to
> >proliferating cryptoalgorithms.  Let's start up a separate thread on
> >CMAC.
> 
> We did talk about it before.  The concept of using the same crypto 
> primitive came up elsewhere and that sounds like a good idea.  Please 
> start that thread of discussion.

I assume that AES CMAC would go as an option into the draft, to be on
one 
hand backward compatible and on the other hand be able to support
different 
algorithms for MAC and encryption. BTW, is there a general
opinion/advice, 
if it is better to use different mechanisms for different services 
(encryption, integrity) to not loose the complete security if one
mechanism 
is broken?

Regards
	Steffen

> 
> 
> >>Q: What are the considerations in truncating cipher-based MAC
> >>outputs?  Specifically, is truncating below half-the-size of the
> >>output (which I vaguely recall as relating to the birthday attack
> >>in case of hash-based MACs -- perhaps it is not) of the 
> cipher- based MAC ok?
> >
> >Ah, good points.  The NIST CMAC specification disallows truncation to
> >MACs shorter than 64 bits.  This is not because CMAC is weaker than
> >an ideal MAC with respect to truncation, though.  CMAC has been shown
> >to be a good pseudorandom function if AES is a good blockcipher (as
> >long as some usage limits are respected), and a PRF essentially is an
> >ideal MAC.  I'm pretty sure that the CMAC specification insists on
> >MACs of at least 64 bits because it feels that a per-MAC forgery
> >probability greater than 2^64 is not acceptable.  No doubt they were
> >not considering the case of stateless codecs, which some SRTP users
> >need only 32-bit MACs.   It is an interesting question as to what tag
> >sizes would be recommended for use with CMAC!
> 
> Let me think more about this.
> 
> 
> >>What would be the strength of the MAC in that case.  If we are
> >>making a case for AES-192 or AES-256, then we have a certain
> >>stronger adversary in mind (one that requires us to move away from
> >>AES-128).  In that case, why is MAC truncation not an issue?
> >
> >That's a good question.  I think that in some circumstances it could
> >make sense to use a short authentication tag and a huge key.  If some
> >unanticipated advance in cryptanalysis enables us to break AES-128
> >but not AES-256, but some user is still okay with accepting one out
> >of a billion forged g.711 packets, this scenario would fit the bill.
> >So the cryptosuites defined in the draft might make sense.  But I
> >take your point that users concerned that AES-128 doesn't have enough
> >security may well not be satisfied with a 32-bit MAC.  It would be
> >good to get some input from the Suite B community on this question.
> 
> Yes, we'll wait to hear from others.
> 
> 
> 
> >>Let's discuss those for now.  I may have more later :-).   Thanks
> >>for doing this!  I was going to ask you about using CMAC in 3711!
> >
> >Any thoughts on whether or not AES-192 should be included?
> 
> I think the use of AES-192 should be specified (at the expense of 
> more work for you :-) ), but let the "market" decide whether the 
> switch is to 192 or 256-bit keys.
> 
> regards,
> Lakshminath
> 
> 
> >David
> >
> >>regards,
> >>Lakshminath
> >>
> >>At 08:15 AM 5/2/2006, David McGrew wrote:
> >>
> >>>Hello,
> >>>
> >>>there has been some interest in using AES with larger key sizes in
> >>>Secure RTP, and some implementations have gone in this direction in
> >>>advance of any specification.  I wrote up an internet draft to fill
> >>>this gap (after trying unsuccessfully to get someone else to write
> >>>it :-) and to provide usage guidance and (eventually) test vectors.
> >>>It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- 
> >>>srtp- big-aes-00.txt
> >>>
> >>>I propose that this draft be adopted for standards track, and I ask
> >>>for your review (if you have an interest in Secure RTP).  
> Please note
> >>>the "Open Questions" section.   The ietf-rtpsec list is 
> copied since
> >>>this draft is potentially interesting there, even though the draft
> >>>has little architectural impact.
> >>>
> >>>Best regards,
> >>>
> >>>David
> 
>