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. 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. That is indicative of the current view on the suitability of using SRTP as a primary security mechanism for classified VoIP apoplications.
Steve
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.