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

From: Matthew Lepinski <[email-masked]>
Date: Thu, 16 Oct 2014 16:39:25 -0400

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 /

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Fri, 17 Oct 2014 15:17:07 +0000

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
[email-masked]  | of thinking we used when we created them." 
                |              - Albert Einstein -
----------------+--------------------------------------------------

-----Original Message-----
From: Matthew Lepinski [mailto:[email-masked]] 
Sent: Thursday, October 16, 2014 4:39 PM
To: [email-masked]; [email-masked]; [email-masked]
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.

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 /

---

From: Matthew Lepinski <[email-masked]>
Date: Sun, 26 Oct 2014 20:18:07 -0400

I gave this a bit more thought and I also am not able to come up with
any good security reason to keep the master salt secret.

I believe that any of the three text changes that you suggest would be
perfectly fine. Any of them would be an improvement over the current
text.

Thanks for taking the time to address this minor concern.
- Matt Lepinski