Subject: [AVTCORE] Comments on draft-ietf-avt-srtp-aes-gcm-01

From: "Peck, Michael A" <[email-masked]>
Date: Mon, 12 Sep 2011 13:33:56 -0400

Hi,

I support the publication of draft-ietf-avt-srtp-aes-gcm.  

I have a few minor comments on the document:

Section 1.1 Crypto Context
For clarity, suggest changing the text:
which results in authentication of each participant in the SRTP session and in their possession of a shared secret master key and a shared master salt
to:
which results in authentication of each participant in the SRTP session and possession by each participant of a shared secret master key and a shared master salt

s/maser key/master key
	
Section 1.2.3:
s/inititialition/initialization 

s/6-byte/6-octet
(for consistency with the rest of the paragraph)

Section 1.2.4:
"12-octet SRTP session encryption salt" - should it say SRTCP instead of SRTP here?

Section 1.2.5:
s/plaintext, which/plaintext and which

Section 1.2.6:
Missing a . at the end of the paragraph.

Section 1.2.6.1:
RFC 3711 section 3.4 states that the authentication tag is a REQUIRED field in SRTCP.
But draft-ietf-avt-srtp-aes-gcm-01 states in Figures 4 & 5 that the authentication tag is NOT RECOMMENDED for SRTCP (because GCM already places the authentication tag elsewhere).
It may be appropriate to add some explanatory text about why the RFC 3711 section 3.4 requirement for an authentication tag does not apply here.

"and eight octets and the encryption flag are treated as plaintext" - I don't understand this wording - I don't know which eight octets it is referring to, and the encryption flag is treated as AAD, not plaintext.
Perhaps just remove this whole sentence and rely on the diagram instead - changing the paragraph text to just:
"Figure 4 below shows how fields of an SRTCP packet are to be treated when the encryption flag is set to 1."

Section 2.2:
s/AEAD-AES-128-GCM-8/AEAD_AES_128_GCM_8
s/AEAD-AES-256-GCM-8/AEAD_AES_256_GCM_8

Section 4:
Should the DTLS-SRTP SRTP Protection Profiles defined here follow the example of RFC 5764 Section 4.1.2 and also include parameters? (cipher, cipher_key_length, cipher_salt_length, maximum lifetime, auth function, auth_key_length, auth_tag_length)  
We have a table in Section 7 of draft-peck-suiteb-dtls-srtp that may be a good fit here.

Thanks,
Mike

--
Michael Peck
The MITRE Corporation

---

From: David McGrew <[email-masked]>
Date: Tue, 13 Sep 2011 07:01:26 -0700

Thanks for the comments, Michael.  More inline:

On Sep 12, 2011, at 10:33 AM, Peck, Michael A wrote:

> which results in authentication of each participant in the SRTP  
> session and in their possession of a shared secret master key and a  
> shared master salt
> to:
> which results in authentication of each participant in the SRTP  
> session and possession by each participant of a shared secret master  
> key and a shared master salt
>
> s/maser key/master key
> 	
> Section 1.2.3:

Good catch.

> But draft-ietf-avt-srtp-aes-gcm-01 states in Figures 4 & 5 that the  
> authentication tag is NOT RECOMMENDED for SRTCP (because GCM already  
> places the authentication tag elsewhere).
> It may be appropriate to add some explanatory text about why the RFC  
> 3711 section 3.4 requirement for an authentication tag does not  
> apply here.
>
> "and eight octets and the encryption flag are treated as plaintext"  
> - I don't understand this wording - I don't know which eight octets  
> it is referring to, and the encryption flag is treated as AAD, not  
> plaintext.
> Perhaps just remove this whole sentence and rely on the diagram  
> instead - changing the paragraph text to just:
> "Figure 4 below shows how fields of an SRTCP packet are to be  
> treated when the encryption flag is set to 1."

Looks like a cut/paste error.  The "first 8 octets" was supposed to  
refer to the eight octets of the SRTCP header; it was supposed to have  
read "When the encryption flag is set to 1, the first 8-octets, the  
encryption flag, and the SRTCP index are treated as AAD.  All data  
between the SRTCP header and the encryption flag are treated as  
plaintext."

> Should the DTLS-SRTP SRTP Protection Profiles defined here follow  
> the example of RFC 5764 Section 4.1.2 and also include parameters?  
> (cipher, cipher_key_length, cipher_salt_length, maximum lifetime,  
> auth function, auth_key_length, auth_tag_length)

That sounds like a good idea, thanks for the pointer.

David

---

From: Qin Wu <[email-masked]>
Date: Thu, 22 Sep 2011 20:11:44 +0800

Hi,
This draft is well written. I would like to see this work moving forward.
Here are my minor comments to this document:

1. Section 1, Second Paragraph

  [Qin]: It looks SRTP (together with SRTCP) utilizes AES as the default cipher.
  However in some case(e.g., in ITU-T H.235.8), Public key cryptography be used with SRTP to provide end to end confidential and 
  authentication. So is it fair to assume in SRTP, both sender and receiver only use symmetric cryptography? what if asymmetric cryptography?

2. Section 1.1 Second Bullet

 [Qin]: It is not clear why four instantiations is required for each participant in the session,
 I think it is better at least to  have  a reference  to put here.

3. Section 1.2.1, First Paragraph

   [Qin]: Is the AEAD authentication tag is authentication tag 
   defined in SRTP/SRTCP packet? If not, how they are different? If yes,
   it is better to be clear about this in the draft.

4. Section 1.2.1, Second Pragraph

[Qin]: Should it say the optional SRTP Authentication Tag is NOT Recommended to be present
 to be consistent with the figure in section 1.2.5.

5. Section 1.2.5

  [Qin]: Should it also say authentication tag is not reccommended in the note to the figure?

6.Section 2.1 Four Paragraph

[Qin]: How the number of invocations is calcualted for SRTP/SRTCP respectively?

7. Section 2.2, Table 1

[Qin]: You also need to support the algorithm specified in [RFC5282],Should it say 
A detailed description of the AES-GCM family can be found in
   [RFC5116][RFC5282]?

8. Section 2.2 Last Paragraph

[Qin]: You didn't mentioned IV is formed from invocation counter in the section
1.2.2, rather than you point out "The packet counter is closely related to the invocation field",
what is missing?

 [Qin]:It is not clear to me how the invocation counter is related to each instantiation of AES-GCM?

9.Section 3

[Qin]: I can not understand this formulation and table. how do you get this formulation and table?
what's the rationale behind?

10.Section 4

[Qin]:It looks not complete since you didn't specify the SRTP transform parameters fro each profile.

Regards!
-Qin