Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

["Ejzak, Richard P (Richard)" <[e-mail]>]

Hi Salvatore,
“are you proposing that when/if we will eventually use SDES we have to assure that the key exchanged
is the same key used by the DTLS session, on top of which runs Datachannel?” is a reasonable interpretation of what I am proposing, although I would have described this as my “preference” rather than a concrete proposal.  We could mix SDES for voice/video with DTLS for DataChannels in these scenarios, but an all-SDES approach (for keying) would be more efficient.

I know that this option is not currently defined, although it does seem technically feasible (which is why I asked to ekr to comment).

BR, Richard

From: Salvatore Loreto [mailto:[e-mail]]
Sent: Tuesday, April 30, 2013 1:33 AM
To: Ejzak, Richard P (Richard)
Cc: Bernard Aboba; [e-mail]
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

Hi Richard

I think that we have two aspects here that we have to consider and see what the working group opinion is about them:
the first is related to the use cases you are describing below in your mail..
the second is related to what means or should mean "to have an SDES option for DataChannel"

here I am considering only the latter trying to understand if

as you know the DataChannels run directly on top of the DTLS stack, so it is the DTLS sessios as such
that provides security, confidentiality etc etc..
SRTP relies on an external key management protocol to set up the key necessary to perform the job,
and SDES is just a possible exchange method.

so when you propose "to have an SDES option for DataChannel"
are you proposing that when/if we will eventually use SDES we have to assure that the key exchanged
is the same key used by the DTLS session, on top of which runs Datachannel?
or is something different ? if this is the case can you explain it?

br

/Sal



On 4/29/13 4:40 PM, Ejzak, Richard P (Richard) wrote:
I responded to this question earlier so didn’t want to repeat myself, but see now that it was either missed or otherwise not accepted.

Quoting my earlier email from 4/25:


“Legacy devices support more than just audio and video media.  We will need to occasionally transport protocols like T.140, MSRP, BFCP, and/or RTSP in some cases, and the primary options are to transport them over DataChannels or WebSockets.  A network server will be needed to do transport level interworking, of course.  It would be useful in these cases to have an SDES option for DataChannels.  Not essential, but useful.  End-to-end security is not even an issue in this case due to the need for transport level interworking.”

After further consideration, I don’t currently see a use case for RTSP, but I still do for the others.  If we have a legacy endpoint doing T.140 and audio, for example, it would be useful to be able to multiplex the audio together with T.140/DC at the browser, and to put a box in the network to adapt them as necessary for the legacy endpoint (decode, demux, DC-to-RTP i/w for T.140, possibly transcoding).  SDES for DC just makes this easier to do.

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Bernard Aboba
Sent: Saturday, April 27, 2013 10:53 AM
To: Salvatore Loreto
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

I don't understand it either.

Salvatore Loreto <[e-mail]<mailto:[e-mail]>> wrote:

I am also puzzled about the request for SDES also in DataChannel.

/Salvatore

On 4/26/13 2:35 PM, Iñaki Baz Castillo wrote:

SDES is obviously requested for legacy interop at RTP layer. Why do we need SDES in DataChannel if this is a complete new technology?

--
Iñaki Baz Castillo
<[e-mail]<mailto:[e-mail]>>
El 25/04/2013 23:55, "Ejzak, Richard P (Richard)" <[e-mail]<mailto:[e-mail]>> escribió:
I also agree that we should support SDES in addition to DTLS-SRTP.

This raises a further question about SCTP/DTLS for DataChannels.  It seems that if we support SDES-SRTP, don't we also need to provide an SDES keying mechanism for DataChannels?  Ekr: What is needed to realize this?

Richard Ejzak

> -----Original Message-----
> From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On
> Behalf Of Matthew Kaufman (SKYPE)
> Sent: Thursday, April 25, 2013 3:28 PM
> To: Bogineni, Kalyani; 'Cullen Jennings'; [e-mail]<mailto:[e-mail]>
> Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
>
> I agree. The ability to set the cipher suite and keys from JavaScript
> is critical for certain applications. SDES is the best we'll get with
> SDP as the API. DTLS-SRTP-only would be unacceptably limiting.
>
> Matthew Kaufman
>
> > -----Original Message-----
> > From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On
> > Behalf Of Bogineni, Kalyani
> > Sent: Thursday, April 25, 2013 1:21 PM
> > To: 'Cullen Jennings'; [e-mail]<mailto:[e-mail]>
> > Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
> >
> > We would like to support the use of SDES as a keying method for
> WebRTC.
> >
> > Kalyani Bogineni
> > Verizon
> >
> > -----Original Message-----
> > From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On
> > Behalf Of Cullen Jennings
> > Sent: Thursday, April 25, 2013 11:57 AM
> > To: [e-mail]<mailto:[e-mail]>
> > Subject: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
> >
> >
> > The working groups committed some time ago to have a further
> > discussion on whether SDP Security Descriptions (RFC 4568 aka SDES)
> > would be usable as a keying method for WebRTC.  As we prepare for
> that
> > discussion, we'd like to have expressions of interest or support for
> > that approach which indicate the general outlines of support
> proposed.
> > If you wish to make such an expression of support, please send it to
> the chairs or the list.
> >
> > Cullen, Magnus, & Ted <The Chairs>
> >
> >