Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

From: Qin Wu <[email-masked]>
Date: Thu, 05 May 2011 19:28:38 +0800

Some fairly minor comments below.  Overall I think the document provides useful mechanism to deal with tradeoff between RTP header extension encryption and RTP header
compression efficiency when we use multiple header extension.

Section 3 Encryption Mechanism
"
  To encrypt (or decrypt) an encrypted extension header, an SRTP
   participant first generates a keystream for the SRTP extension
   header.  This keystream is generated in the same manner as the
   encryption keystream for the corresponding SRTP payload, except the
   the SRTP encryption and salting keys k_e and k_s are replaced by the
   keys k_he and k_hs, respectively.
"
[Qin]: Is it possible to use the same keystream and crypto-suite for SRTP payload
to provide encryption for the payload of header extension element?
What's the benefit to choose the different keystream and crypto-suite for header extension elements?
Can we say the same keystream and  crypto-suite for SRTP payload can be applied to header extension elements?

Section 4:
"
Encrypted header extension elements are signaled in the SDP extmap
   attribute, using the URI "urn:ietf:params:rtp-hdrext:encrypt",
   followed by the URI of the header extension element being encrypted
   as well as any extensionattributes that extension normally takes.
"
[Qin]: Are you going to define new URI for Encryption of Header Extensions or use existing URI?

Section 4:

[Qin]: If one header extension has three elements, 
a) the header extension and elements header will not be encrypted, only payload of each elements need encryption 
b) or both elements header and elements payload will be encrypted?
I believe it is former.

[Qin]: If the number of header extension element included in each RTP packet changes during a stream, e.g., Firstly three header extension elements
to be encrypted carried in the first RTP packet are sent to the receiver, and then, two header extension elements carried in 
the second RTP packet are sent to the same receiver, is the receiver aware of this change and  choosing the right encryption mask? How?
based on non-encrypted header?

[Qin]: If there are no payload for header extension elements, i.e., the length of header extension elements is zero, the mechanism described in this document
does not apply to this case, right?

Regards!
-Qin
----- Original Message ----- 
From: "Jonathan Lennox" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 28, 2011 5:08 PM
Subject: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

Hello, all --

I've updated my draft on encrypting RTP header extensions, targeting the draft at the AVTCore WG, in the hope that the group will find it a suitable starting point for the WG milestone.

This version of the draft has no substantial changes from draft-lennox-avt-srtp-encrypted-extension-headers-02, only the name change and some reference updates.

Begin forwarded message:

> From: "[email-masked]" <[email-masked]>
> Date: March 28, 2011 11:00:01 AM GMT+02:00
> To: "[email-masked]" <[email-masked]>
> Subject: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
> Reply-To: "[email-masked]" <[email-masked]>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)
> Author(s)       : J. Lennox
> Filename        : draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
> Pages           : 8
> Date            : 2011-03-28
> 
> The Secure Real-Time Transport Protocol (SRTP) provides
> authentication, but not encryption, of the headers of Real-Time
> Transport Protocol (RTP) packets.  However, RTP header extensions may
> carry sensitive information for which participants in multimedia
> sessions want confidentiality.  This document provides a mechanism,
> extending the mechanisms of SRTP, to selectively encrypt RTP header
> extensions in SRTP.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

--------------------------------------------------------------------------------

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 5 May 2011 11:34:20 -0400

> compression efficiency when we use multiple header extension.

That's good to hear!  Responses inline.

> Can we say the same keystream and  crypto-suite for SRTP payload can be applied to header extension elements?

It definitely uses the same cryptosuite, but it can't be the same keystream -- if the payload and the extension elements are encrypted with the same keystream, you have a two-time-pad security failure.

In principle you could use a different region of the same keystream, but there's no obvious way to do that in a way that's backward-compatible with existing SRTP.

Since SRTP implementations are already generating six separate keys based on the master key (encryption, salting, and authentication for both RTP and RTCP) and two keystreams (for RTP and RTCP), adding two additional keys and one additional keystream doesn't seem like a particularly large implementation burden.

> [Qin]: Are you going to define new URI for Encryption of Header Extensions or use existing URI?

The intention is that the new URI you quoted specifies generic encryption, and the extmap attribute takes as a parameter the existing URI describing the header being encrypted.

For example, encrypted SMPTE timecodes would be described as:

a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt urn:ietf:params:rtp-hdrext:smpte-tc 25@600/24 

> b) or both elements header and elements payload will be encrypted?

That's correct.

> based on non-encrypted header?

The header extension elements are identified by the (unencrypted) header extension element headers, and you know based on the SDP which ones are encrypted. Thus, the encryption mask can be computed on a packet-by-packet basis.

> does not apply to this case, right?

For the one-byte-header form of header extension elements (0xBEDE), RFC 5285 doesn't support zero-length header extension elements, so it's moot.

For the two-byte-header form of header extension elements (0x100x), indeed this mechanism doesn't apply to zero-length extension elements.  The mechanism also doesn't apply to the long-form extension's app bits (the unspecified four bits of the "specified by profile" field).

--
Jonathan Lennox
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Fri, 06 May 2011 09:25:48 +0800

Thanks for clarification. I removed the fixed comments, please see inline.
----- Original Message ----- 
From: "Jonathan Lennox" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 05, 2011 11:34 PM
Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

[Qin]: I agree using the same keystream to encrypt twice  will cause two-time pad security failure issue,
 i.e., first use the keystream to encrypt STRP payload, and then use the same keystream to encrypt 
header extension elements.

However if we regard the payload of header extension elements and SRTP payload as a big payload, 
we only need to use the same keystream to encrypt this big payload once. there is no two-time pad 
security issue, right?

[Qin]: True.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 5 May 2011 21:29:27 -0400

> we only need to use the same keystream to encrypt this big payload once. there is no two-time pad 

That's true, but it wouldn't be backward-compatible with existing receivers, which understand SRTP but ignore extension headers they're not familiar with -- the keystream would start in the wrong place.

--
Jonathan Lennox
[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Fri, 06 May 2011 09:45:41 +0800

----- Original Message ----- 
From: "Jonathan Lennox" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 06, 2011 9:29 AM
Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

[Qin]: So who will care header extension elements? the intermediary node or receiver who are signalled by SDP.
--
Jonathan Lennox
[email-masked]