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

[Christer Holmberg <[e-mail]>]

Hi,

Based on the input from people, I suggest the following text for the new 'DTLS Considerations' section:

-------------

12.  DTLS Considerations

   One or more media streams within a BUNDLE group might use the
   Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order
   to encrypt the data, or to negotiate encryption keys if another
   encryption mechanism is used to encrypt media.

   When DTLS is used within a BUNDLE group, the following rules apply:

   o  There can only be one DTLS association [RFC6347] associated with
      the BUNDLE group;

   o  Each usage of the DTLS association within the BUNDLE group MUST
      use the same mechanism for determining which endpoints (the
      offerer or answerer) becomes DTLS client and DTLS server; and

   o  If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include
      the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message
      [RFC5764], The client MUST include the extension even if the usage
      of DTLS-SRTP is not negotiated as part of the session.

   NOTE: The inclusion of the 'use_srtp' extension during the initial
   DTLS handshake ensures that a DTLS renegotiation will not be required
   in order to include the extension, in case DTLS-SRTP encrypted media
   is added to the BUNDLE group later during the session.

------------


Regards,

Christer






-----Original Message-----
From: mmusic [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: 31. toukokuuta 2015 10:03
To: Roman Shpount
Cc: [e-mail]; [e-mail]
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

Hi,

>>> 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?
>
> 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).

Anyone from the browser community that can comment on this?

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

Currently, I am not aware of any scenarios where people would use BUNDLE without SRTP - or at least using clients that wouldn't support SRTP.

But, as the current trend seems to be to put more and more protocols on DTLS, I think one can assume that there will also be use-cases without SRTP in future.

Regards,

Christer

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic