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

[Christer Holmberg <[e-mail]>]

Hi,

> 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.
>
>Christer,
>
>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?

Regards,

Christer





On Thu, May 28, 2015 at 7:31 AM, GUBALLA, JENS (JENS) <[e-mail]> 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 https://tools.ietf.org/html/draft-ietf-tls-tls13-05.

BTW, I prefer the term "renegotiation" over "re-handshake" or "re-keying", refer to https://tools.ietf.org/html/draft-guballa-tls-terminology-01.

Best regards,
Jens

>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> From: Roman Shpount [mailto:[e-mail]]
> Sent: 28 May 2015 05:20
> To: Christian Groves
> Cc: Christer Holmberg; Makaraju, Maridi Raju (Raju); [e-mail];
> [e-mail]
> 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
> <[e-mail]> 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
>