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

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

Hi Jonathan,

From: Jonathan Lennox <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 14, 2012 12:37 PM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>
Cc: Ron Even <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext

Hi, David -- thanks for your comments!

On Sep 12, 2012, at 8:08 AM, David McGrew (mcgrew) wrote:

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.

Since the header extension elements' header bytes are sent in the clear, the mask can be calculated for each packet.  You know from the SDP which header extension IDs correspond to encrypted elements.  When you parse a header extension, you see the ID and length for each header extension element, and calculate the mask accordingly.

That makes sense.   I went back for a second look at the draft, and I realized that this was my stumbling block: I did not keep in mind the fact that "The encryption mask corresponds to the entire payload of each header extension element that is encrypted."   I was (incorrectly) thinking that a mask might cover only part of a payload for a particular header extension.


The mask can differ on a packet-by-packet basis, since different header extension elements (either encrypted or plaintext) can be sent in different packets.

I can clarify this in the text, if you think it would be helpful.

That might be useful (though I am the only person that got confused on this point :-)


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.

That's a good idea.  I think an earlier version of the draft may have presented it in the alternate way you suggest; but I agree, giving both descriptions, and making it clear that they're equivalent, would probably be helpful.


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

I agree, good idea.

Sounds good.   Let's make this an RFC.

David


Thanks!

--
Jonathan Lennox
[e-mail]<mailto:[e-mail]>