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

[David McGrew <[e-mail]>]

Hi Qin,

thanks for your comments,

On Sep 22, 2011, at 5:11 AM, Qin Wu wrote:

> 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?
>

only symmetric crypto is in scope for SRTP.  To establish SRTP  
sessions using public keys, the best standard to use is DTLS-SRTP (RFC  
5764).  ZRTP is similar (but not a standard).   Alternatively, one can  
use public key cryptography to protect signaling (which should be done  
anyway ;-) and then pass the SRTP keys through it.


> 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.

In the text " Rationale. Some applications use the Authentication Tag  
" I will add "SRTP Authentication Tag" to make that clear.

>
> 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.

These terms are defined to be equivalent in RFC 2119.  But if you  
think it is clearer, we could change "SHOULD NOT be present" to "is  
NOT RECOMMENDED and SHOULD NOT be present".   That is fine with me.

>
> 5. Section 1.2.5
>
>  [Qin]: Should it also say authentication tag is not reccommended in  
> the note to the figure?
>

Sure.

> 6.Section 2.1 Four Paragraph
>
> [Qin]: How the number of invocations is calcualted for SRTP/SRTCP  
> respectively?

Here an invocation means of the AEAD encrypt or decrypt function.  It  
is equivalent to the number of packets that are being protected.

>
> 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]?

Good point.

>
> 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?
> 	

Good point.

> 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?
>

The table entries are computed using the formula in the paragraph  
above.  To limit the success probability to 2^-30 when using an 8- 
octet tag, for instance, one must limit the number of tries that an  
attacker has to 2^32.   Here a "try" is when the attacker gets the  
SRT[C]P receiver to accept a maliciously chosen packet, e.g. as part  
of a forgery attempt.

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

Yes, good point.

thanks again,

David

> Regards!
> -Qin