Last Call Review of draft-ietf-avt-srtp-big-aes-
|Requested revision||No specific revision (document currently at 06)|
|Type||Last Call Review|
|Team||Security Area Directorate (secdir)|
|I-D last updated||2011-01-05|
Secdir Last Call review of -??
by Hilarie Orman
Security review of draft-ietf-avt-srtp-big-aes-05.txt Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a very well-written document about using AES-192 and AES-256 with RTP, and I have only a few comments. There is no comment on why AES-192 might be used. There is a comment about AES-128 vs. AES-256, but AES-192 seems to fall into a useless middle ground. I'd like to see some comment about it. Section 3.1 "Usage Requirements" might be easier to understand if it said that "When AES_192_CM is used for encryption, the key derivation function MUST have a cryptographic strength of at least 192 bits; AES_192_CM has this strength, AES_128_CM does not." Similarly for AES_256_CM. It would be helpful to note which data items are specific to SRTP. The draft says that it uses the terminology of "Section 4.1.1 of [RFC3711]", but oddly enough, the "SSRC" is not defined in that document, either. One must go back to RFC3550 for its definition. I was flummoxed by the math of "if kdr=0 then (index DIV kdr) = 0". RFC3711 section 4.3.1 does explain it; it's kind of confusing to have to switch back and forth between the two documents. The block counter "b_c" is two octets, but the "default key lifetime" is 2^31. Is this perhaps the "maximum" key lifetime? Should implementors introduce an internal counter to keep track of the history of key usage (across sessions?)? Perhaps earlier documents explain this? Hilarie