Subject: Re: [AVT] WGLC for draft-ietf-avt-srtp-big-aes-03

From: David McGrew <[email-masked]>
Date: Wed, 15 Sep 2010 05:18:47 -0700

Hi Jonathan,

thanks for your excellent comments.  I have posted version 04 of the  
draft this morning, correcting most of the points that you raise  
(except for the suggestion on more test cases, which I suggest should  
be future work that is generic to SRTP and not specific to big-AES).

On Jun 15, 2010, at 9:22 AM, Jonathan Lennox wrote:

> I have no objections to the normative content of this draft.
>
> I have also contributed running code that implements this draft to  
> the open-source libsrtp project.

... and thanks for the contribution too!

>
>
> Non-normative content:
>
> It would be useful to have a rationale as to why it's not felt to be  
> necessary for the crypto suites defined in this document to use to  
> the SHA-2 family of hash functions (SHA-256, etc) for authentication.
>

The security considerations section says (last paragraph):

It is desirable that AES_192_CM and AES_192_CM_PRF be used with an
authentication function that uses a 192 bit key, and that AES_256_CM
and AES_256_CM_PRF be used with an authentication function that uses a
256 bit key.  However, this desire is not regarded as
security-critical.  Cryptographic authentication is resilient against
future advances in cryptanalysis, since the opportunity for a forgery
attack against a session closes when that session closes.

I have added "For this reason, this note defines new ciphers, but not  
new authentication functions." after that text to address your point.

> For the test cases, it would be useful to have a testcase with non- 
> zero values for the ROC, SSRC, and sequence number, to protect  
> against implementations failing to initialize those fields.
>
> It would also be useful to have test cases that illustrate the  
> entire process from master key to encrypted and authenticated SRTP  
> and SRTCP packets.  The existing test cases aren't sufficient for  
> black-box testing, since session keys and keystreams are usually  
> internal to an implementation.

These are good points about how the SRTP test cases could be improved,  
but I suggest that we take these suggestions up in future work on  
SRTP, rather than in this particular draft.   The existing test cases  
take up four and a half pages, and they've been checked by John  
Matsson, so I don't want to alter them.

I have a scriptable AES app that I used to generate the test cases for  
the big-aes draft, which I could use to generate future test cases  
that are independent from libsrtp.  However, there will still need to  
be a bunch of manual steps to build a black-box test case, so I don't  
think we should put this work item on the critical path for big-aes  
(which is a blocking item for Phil's ZRTP).   The big-aes draft  
already has better test cases than RFC 3711 already ...

>
>
> None of these issues should be seen as blocking the document.
>
>
> Editorial:
>
> Section 2, paragraph 2: extra space before period:
>
>   using the terminology from Section 4.1.1 of [RFC3711] .  In this
>                                                        ^

fixed

>
> Section 3, paragraph 1: extra space before close parenthesis:
>
>   the phrase "key derivation function". ) This key derivation function

fixed

>                                        ^
>
> Section 3, paragraph 3: inconsistent quotation:
>
>   operation, and the "AES Encrypt" operation uses AES-128, AES-192, or
>   AES-256 for the "AES-CM PRF", AES_192_CM_PRF, and AES_256_CM_PRF,
>                   ^          ^  ^            ^      ^            ^
>

The inconsistency is carried over from RFC 3711, which uses both AES- 
CM and AES_CM.  I'll change the draft to use AES_CM, then point out  
that AES-CM is also used in the RFC.

Here's the changes:

Section 4.3.3 of <xref target="RFC3711"/> defines an AES counter mode
key derivation function, which it refers to as AES_CM PRF (and
sometimes as AES-CM PRF).

...

In this diagram, the symbol (+) denotes the
bitwise exclusive-or operation, and the "AES Encrypt" operation uses
AES-128, AES-192, or AES-256 for the AES_CM PRF, AES_192_CM_PRF, and
AES_256_CM_PRF, respectively

> Section 4, title: typographical error
>
> 4.  Crypto Suties
>           ^^^^^^
>

fixed.

David

> -- 
> Jonathan Lennox
> Vidyo, Inc
> [email-masked]