Re: [secdir] SECDIR Review of draft-ietf-avtcore-srtp-aes-gcm-14

["Igoe, Kevin M." <[e-mail]>]

I have no problems with the changes you suggest.  

As to the use of a secret salt, sction 3.2.1 of RFC 3711 says the 
master salt may be either public or secret.  Annoyingly, it never 
again mentions any distinction betwixt public and secret master keys.

Neither myself nor my colleagues could come up with a sound security 
reason for using a secret master salt, but all secret vslues need to
be properly erased.  I see three (3) options:

a) change the first bullet of section 14.1 to read:

"  - The master salt MUST be properly erased when it is no longer needed."


b)  Adding the following two (2) sentences to the end of the first 
paragraph of section 14.1.

  "RFC 3711 provides for the use of either a public master salt or a 
  secret master salt.  When there is any doubt as to which option has 
  been selected, for the purposes of this section the master salt should 
  be treated as if it was secret." 

c) Put at the end of the first bullet:

  "When in doubt as to whether the master salt is public or secret,
   it should be erased as if it was secret."


No real preference, but option a) is the easiest typographically.

----------------+--------------------------------------------------
Kevin M. Igoe   | "We can't solve problems by using the same kind
[e-mail]  | of thinking we used when we created them." 
                |              - Albert Einstein -
----------------+--------------------------------------------------

-----Original Message-----
From: Matthew Lepinski [mailto:[e-mail]] 
Sent: Thursday, October 16, 2014 4:39 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: SECDIR Review of draft-ietf-avtcore-srtp-aes-gcm-14

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 document specifies the use of the Advanced Encryption Standard
(AES) in both Galois Counter Mode (GCM) and CBC Counter Mode (CCM) as an Authenticated Encryption with Additional Data (AEAD) cipher-suite for the SRTP protocol. This is the first AEAD specification for SRTP.
However, this specification is consistent with other AEAD work in the IETF (i.e., RFC 5116).

I found no significant issues in the review of this document and believe that it is ready for publication.

Nits (consider the following suggestions):

Section 3b: s/(as well one or more /(as well as one or more /

Section 6: s/XORed to the plaintext to form /XORed with the plaintext to form /

Section 9.1: s/XORed to the 12-octet salt to form /XORed with the 12-octet salt to form /

Section 10.1: s/XORed to the 12-octet salt to form /XORed with the 12-octet salt to form /

Section 11: s/accept inputs with varying lengths /accept inputs of varying lengths /

Section 14.1: You use the phrase "If the master salt is to be kept secret". However, I am not sure how an implementer is supposed to decide whether or not to keep the master salt secret. If you have any reference on the ramifications of keeping / not-keeping the master salt secret, it would be helpful to include such a reference.

Section 14.2: s/authentication value until by chance they hit a valid /authentication value until, by chance, they hit a valid /