Hi Steve, On May 4, 2006, at 7:36 AM, Stephen Kent wrote:
At 4:14 AM -0700 5/4/06, David McGrew wrote:...One reason that I can think of for implementing AES-256 in this case would be to conform to Suite B "TOP SECRET". But there are not many other good reasons for implementing that key size at the present time. The spec does promote algorithm agility, which is a good thing. I guess that the trick is to provide for that agility without making interoperability harder. I tried to do address the interoperability issue in the draft by pointing out that AES-256 is an addition to, not a replacement for, for AES-128. I also tried to write the security considerations in such a way that encourages the use of AES-128. The bigger key sizes are a hedge, as you put it, and for almost all uses they are not needed at present. At least I tried to convey that impression - I'd value comments from readers, and I'dbe happy to add or modify text in this direction.David,I don't think Suite B is relevant here. To be approved for protecting classified data at the TS level, a product will have to meet a lot of requirements, and the algorithm and key size are two of the easiest ones to meet.
I take your point here. At http://www.nsa.gov/ia/industry/ crypto_suite_b.cfm, we're told that a CMVP evaluation is all that's needed to protect unclassified information (at which level AES-128 is considered sufficient, but AES-256 is allowed), but an NSA evaluation is required for implementations that protect classified info (which would require AES-256). An important question is: will the adopters of Suite B for the protection of unclassified information regard AES-256 as desirable?
SRTP is carefully engineered to minimize overhead, and for commercial applications the tradeoffs that were made re security seem reasonable. However, there is non indication that these tradeoffs are appropriate for use in the classified data protection area. I note that DoD folks are working hard on defining how to use ROHC with IPsec, and a primary motivation is to enable use of IPsec, as implemented in HAIPS-compliant devices, to protect voice traffic.
For sure the interest in ROHC stems from a desire to protect VoIP with ESP, and IMO this makes good sense.
That is indicative of the current view on the suitability of using SRTP as a primary security mechanism for classified VoIP apoplications.Steve
Perhaps, though SRTP is comparable to ESP transport mode, and header compression in ESP is applicable to tunnel mode. Also, I've heard that AES-256 in SRTP has been discussed in other US DoD contexts, FWIW. But at any rate, I can't speak for the Suite B community, and I'm glad to take input from them on the content of the draft.
There has been a bunch of good discussion on this draft, and my feeling is that we ought to standardize how to use AES-256 as an option in SRTP, but provide lots of guidance about the sufficiency of AES-128. Given that TLS and IPsec provide AES-256 options, I don't see how we can argue otherwise, and I'm concerned that incompatible implementations would proliferate in the absence of a standard. If the reference to Suite B is inappropriate, then it can be amended or removed.
David
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.