Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

Christer Holmberg <> Fri, 29 May 2015 05:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 73D6A1B2A12 for <>; Thu, 28 May 2015 22:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E7jxUWnutMyy for <>; Thu, 28 May 2015 22:25:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D99B1A92B4 for <>; Thu, 28 May 2015 22:24:06 -0700 (PDT)
X-AuditID: c1b4fb2d-f794d6d000004501-3b-5567f7f4b770
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 5E.58.17665.4F7F7655; Fri, 29 May 2015 07:24:04 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Fri, 29 May 2015 07:24:04 +0200
From: Christer Holmberg <>
To: Roman Shpount <>, "GUBALLA, JENS (JENS)" <>
Thread-Topic: [MMUSIC] Bundling data channel and RTP? - Text proposal
Date: Fri, 29 May 2015 05:24:03 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3VvfL9/RQg4t3tC2+vG9ksTi42c9i 6vLHLBYrNhxgtZhxYSqzA6tH67O9rB5/339g8liy5CeTx4rzM1k8bk0pCGCN4rJJSc3JLEst 0rdL4Mp4vvMFa0GDScXecyfZGxivGHUxcnJICJhIXFjwhxnCFpO4cG89WxcjF4eQwFFGif4T 01hBEkICixklnp2U72Lk4GATsJDo/qcNYooIJErsa9EEqWAW6GGUWHU+B8QWFnCR+LWkhwXE FhFwlVjx/DczyEgRgSZGiVP9t8BGsgioSlw8tIQNxOYV8JWY9+IbC8Sq/WwSi95ngdicAoES k9cfAKtnBLrt+6k1TBDLxCVuPZnPBHGzgMSSPeeh7heVePn4HyuErSSx9vB2FpA7mQU0Jdbv 0odoVZSY0v2QHWKtoMTJmU9YJjCKzUIydRZCxywkHbOQdCxgZFnFKFqcWlycm25krJdalJlc XJyfp5eXWrKJERhxB7f81t3BuPq14yFGAQ5GJR7eB+vSQoVYE8uKK3MPMUpzsCiJ83p1hYQK CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHR+cWdZnKf4Ox7F0Gjpue7FN1b/DMs46/Y6cENa sW/J7k97u/O13wZzyESFxkiumn6+o+Pn9l9T6ncrHF7zJaprGvPhO7NfLP8l41Nj0jiVLeXF e06Xd4ui5W4LdNca2oqEzLbK+bR4+o1ZjDFz5/1dyV68Yla7S8gXJx0rqdqbyzb4TH65PFOJ pTgj0VCLuag4EQARBNramQIAAA==
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 May 2015 05:25:12 -0000


> P.S. I forgot to include, as a reason to always mandate "use_srtp" extension, that ability to add extensions on 
> the fly can be removed in TLS 1.3.
>Based on the currents TLS specifications you do *NOT* need to mandate 
>inclusion of “use_srtp” until SRTP/SRTCP is >actually used. If this extension 
>is not specified you can renegotiate the session with the extension enabled. 
>We should still recommend it, in order to avoid  a renegotiation for that 
>purpose when SRTP/SRTCP is added. Also, all current implementation will 
>not inter-operate unless “use_srtp” extension was included from the 
>start, since they do not support renegotiation.
>I am not the member of TLS working group and TLS 1.3 is still fairly early 
>to completely specify how it operates. In particular, it does not include 
>any mechanism for key material update. I am not 100% sure what is 
>going to be supported there and if extensions can be added and removed 
>for an existing DTLS session.
>Given that:
>1. existing implementations will not inter-operate with anything that does 
>renegotiation (and, I have a strong suspicion anything that does not enable "use_srtp" extension)
>2. renegotiation required to add "use_srtp" extension would add an extra round trip
>3. overhead of always having "use_srtp" extensions is minimal
>I would suggest "use_srtp" extension must always be enabled for DTLS session used in bundle.

Assuming SRTP is supported, I assume. If a node doesn't support SRTP to begin with, or if an application is never going to offer (or accept if offered) SRTP, I guess there is no reason to mandate "use_srtp".

Now, there are statements in RFC 5764 saying e.g.:

	"This extension MUST only be used when the data being transported is RTP or RTCP [RFC3550]."

That of course makes sense for a non-BUNDLE DTLS connection, but I wonder whether we somehow explicitly need to say that it doesn't apply for BUNDLE?



On Thu, May 28, 2015 at 7:31 AM, GUBALLA, JENS (JENS) <> wrote:
Hi Christer,

> Hi Roman,
> So, if I understand you correctly, we do *NOT* need to mandate inclusion of
> “use_srtp” until SRTP/SRTCP is actually used. However, we could still
> RECOMMEND it, in order to avoid a re-handshake for that purpose when
> SRTP/SRTCP is added.
[JG] You should take into account that renegotiation will be removed from TLS1.3, refer to

BTW, I prefer the term "renegotiation" over "re-handshake" or "re-keying", refer to

Best regards,

> Regards,
> Christer
> From: Roman Shpount []
> Sent: 28 May 2015 05:20
> To: Christian Groves
> Cc: Christer Holmberg; Makaraju, Maridi Raju (Raju);;
> Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
> If  "use_srtp" extension is specified, there is going to be SRTP/SRTCP keying
> material present and associated with each DTLS cipher state. If DTLS re-
> handshake occurs within the same session, the new RTP/RTCP keying material
> will be negotiated. Since no SRTP/SRTCP packets would be exchanged before
> SRTP/SRTCP stream was added to the bundle, these packets would not contribute
> to cipher state expiration. Cipher state can still expire due to the number of
> data packets transmitted or time, which can still cause new SRTP/SRTCP keying
> material to be negotiated.
> Technically speaking either DTLS client or server can initiate a re-handshake
> at any time. It is an implementation detail on what would cause a re-
> handshake, and it can be done based on the number of packets sent or received,
> or based on time. If re-handshake is done based on the number of packets, both
> SRTP/SRTCP and data packets should have separate counters and cause a re-
> handshake once a certain value is passed.
> As far as I know, DTLS re-handshake is not currently supported by either
> Chrome or Firefox, which means keying material for both data and SRTP/SRTCP
> will stay the same for the duration of the session.
> _____________
> Roman Shpount
> On Wed, May 27, 2015 at 8:06 PM, Christian Groves
> <> wrote:
>       To be clear this means that the SRTP and SRTCP ( (because of the
> possibility of RTP/RTCP muxing) key negotiation occurs even before RTP/STRP
> media is added to the BUNDLE, and the keying material for both are maintained
> for the life of the BUNDLE? If the keys are unused they wouldn't expire
> because max lifetime is based on the number of protected packets.
>       Christian