Security review of Encrypted Key Transport for DTLS and Secure RTP draft-ietf-perc-srtp-ekt-diet-08 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. The draft defines a way by which each sender in a multi-participant session can communicate its encrypting key (called a "master key") to the other participants. In this scheme, all participants learn a key encrypting key (EKTKey) that is used to protect sender's encrypting keys during transit. "This specification also defines a way to send the encrypted SRTP master key (with the EKTKey) along with the SRTP packet ... Endpoints that receive this and know the EKTKey can use the EKTKey to decrypt the SRTP master key which can then be used to decrypt the SRTP packet." I think that the paragraph above would be clearer if "(with the EKTkey)" were changed to "(encrypted with the EKTkey)". I do not understand the security model. If all participants know the EKTkey, then why do senders need to separately select their own individual keys? Cannot all participants use something derived from the EKTkey? Is this a legacy thing? Section 4.4 states that "EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext." Also section 6 (security considerations) states: The EKT Cipher includes its own authentication/integrity check. For an attacker to successfully forge a FullEKTField, it would need to defeat the authentication mechanisms of the EKT Cipher authentication mechanism. Section 4.4.1 state "The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding [RFC5649] algorithm." RFC5649 does not purport to define an authenticated cipher. I am not sure what properties of RFC5649 are the ones that are considered important, so I cannot recommend appropriate wording, though I suspect that "integrity" is the right word, not "authentication". I have one concern about the requirement that all senders change their keys when the EKTKey changes. Suppose a malicious participant manages to create a replay attack that sends a EKTkey message with a key that was previously used, perhaps even the same one that is currently used. This would force all participants to change their keys, perhaps at a very high rate, and this might lead to denial of service. Participants might be advised to ignore EKTkey messages that repeat the current EKTkey. Hilarie