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

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

Hi Christer,

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Freitag, 12. Juni 2015 13:55
> To: mmusic
> Cc: [e-mail]; Roman Shpount; Christian Groves
> ([e-mail]); GUBALLA, JENS (JENS); Martin Thomson
> ([e-mail]); Makaraju, Maridi Raju (Raju); Justin Uberti
> ([e-mail])
> Subject: RE: [MMUSIC] Bundling data channel and RTP? - Text proposal - 
> Second
> try
>
> 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;
[JG] I prefer the term "DTLS connection" over "DTLS association" because
I am not aware that the latter term is defined anywhere in the scope of 
(D)TLS.
RFC6347 is using the terms "connection" and "association" interchangeably 
without
any definition. On the other hand the term "connection" is at least present
in the glossary section of RFC5246.

>
>    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.
[JG] I believe here "session" is referring to "SIP session", not to "DTLS 
session",
right? Should be explicitly stated in any case.

>
>    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.
[JG] "Session": Same comment as above.

Best regards,
Jens

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