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

[Roman Shpount <[e-mail]>]

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.

_____________
Roman Shpount

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