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

From: "GUBALLA, JENS (JENS)" <[email-masked]>
Date: Mon, 1 Jun 2015 12:42:50 +0000

Hi,

[...]
> Another big question how would current browser implementations handle a DTLS
> connection without "use_srtp" extension. I have a strong suspicion that DTLS
> session setup will fail without this extension present. I think, WebRTC
> enabled browsers currently export SRTP key material during session setup 
> even
> if no SRTP traffic is ever sent or received by this connection and fail the
> entire connection if key export fails. This, most likely, can be modified to
> only export SRTP key material when SRTP session is actually created and
> defining some sort of fall back procedure when a media track is actually 
> added
> to a connection without "use_srtp" (either failure or require renegotiation
> with new transport).
>
> To conclude, the group can either decide that all DTLS sessions in bundle
> should be setup with "use_srtp" extension and keep the current 
> implementations
> working as they are currently coded, or allow not to include this extension
> and fix the implementations.
[JG] I see the following potential inter-op issues between DTLS 
implementations
when relying on renegotiation:
  - Support for renegotiation is optional (RFC5246, D.4: "While renegotiation
    is an optional feature, supporting it is highly recommended."), on the
    other hand adding support for SRTP to an existing DTLS connection will
    require renegotiation.
  - Even if renegotiation would be used to add SRTP support: The initial DTLS
    session s1 has been negotiated without "use_srtp". For the renegotiation,
    would it be allowed to resume DTLS session s1, but now adding "use_srtp"?
    Even if that would be allowed from the standards (I am not quite sure 
here),
    would that be supported by implementations? If not, a full handshake would
    be required and a new DTLS session s2 would be negotiated.

Best regards,
Jens
> _____________
> Roman Shpount

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 2 Jun 2015 11:24:53 +0200

Martin Thomson skrev den 2015-05-29 01:06:
> On 28 May 2015 at 16:01, Roman Shpount <[email-masked]> wrote:
>> 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.
>
> I expect that TLS 1.3 will specify a rekeying mechanism, but only for
> its own records (in this context, that means SCTP).  Things that
> depend on exporters (like DTLS-SRTP) will likely get a single, stable
> value.
>

Okay, this is outside of the topic of the recommendation and bundle.

Having no way of renegotiating the SRTP and SRTCP keys will be an issue 
for long-lived RTP sessions.

It may also be an important consideration for how the key-management is 
done in End-to-End secure conferencing work in PERC. Because if one is 
to ensure that only the current group of participants can decode the 
media, then one will have to re-key on each change to the group of 
participants.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------