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

["GUBALLA, JENS (JENS)" <[e-mail]>]

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
>