Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext

["David McGrew (mcgrew)" <[e-mail]>]

Hi Roni,

I've read the new version.   I think this is a good idea, and the draft is well written.   I have only a few specific suggestions.   Most importantly, it is not clear (to me, anyway) how the mask is generated.   It will be essential for interoperability that all of the participants in the session use identical values for the mask, but the draft doesn't describe how a receiver would know the mask value that the sender has selected.  I had expected that the mask value would be sent as a part of "urn:ietf:params:rtp-hdrext:encrypt", or something like that.  I think this point needs to be clarified in the draft.

The header encryption operation is described in a way that would change the CTR (or f8) encryption operation ("The SRTP participant bitwise-ANDs the encryption mask with the keystream to produce a masked keystream").   However, what I hope/expect that implementations will do is implement header encryption in a way that does not change any of the crypto functions.    The header encryption can be described in terms of manipulations of the plaintext and ciphertext, like this:

    EncryptedHeader = (Encrypt(Key, Plaintext)  AND MASK)  OR (Plaintext AND (NOT MASK))

Many implementations would prefer this approach, because it enables them to use their encryption functions in a way that is unchanged.   For instance, the crypto function might be implemented in a separate software library, or provided by a hardware function; the encryption function might be part of a validated crypto module, and thus there would be strong motivation not to alter it (and undo the validation).    The current text in the draft is clear, so I don't recommend changing it.   But I suggest providing an alternative description of the algorithm in a separate paragraph that follows the current description.

The security of the mask-based mechanism is sound, when used with the existing SRTP crypto transforms, as described in Section 3.   However, if the mechanism is applied to other encryption methods, like ECB or CBC, then it would not be a sound approach.   The alternative way of describing the encryption scheme in terms of plaintext manipulations might make it look like the scheme could be applied to ECB or CBC.   So I suggest putting a statement in the security considerations saying "This technique can only be applied to encryption transforms that work by generating a pseudorandom keystream and bitwise exclusive-oring it with the plaintext, such as CTR or f8; it MUST NOT be used with ECB, CBC, or any other encryption method that does not use a keystream, or a loss of security will entail."

David

From: Ron Even <[e-mail]<mailto:[e-mail]>>
Date: Monday, September 10, 2012 11:32 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext

Hi,
Plesae review the document
Roni

On Mon, Aug 27, 2012 at 8:38 PM, Roni Even <[e-mail]<mailto:[e-mail]>> wrote:
Hi,
I would like to start a second WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-02 .
The draft finished a WGLC and there were comments from the WG chairs. These comments were addressed but since we did not have enough reviewers we are asking for more reviews

Please review the documents and send any comments by September 15th

Thanks
Roni Even
AVTCore co-chair