W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2011

Re: PeerConnection Data Channel

From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 3 Sep 2011 08:10:48 -0700
Message-ID: <CABcZeBN-pmnbNjfiFNkqbc0QdE-iTRdeEkqvZ1xuPV+3-9P9UQ@mail.gmail.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>
Cc: Justin Uberti <juberti@google.com>, public-webrtc@w3.org
On Fri, Sep 2, 2011 at 11:17 AM, Matthew Kaufman
<matthew.kaufman@skype.net> wrote:
> On 9/2/11 7:12 PM, Justin Uberti wrote:
> On Fri, Sep 2, 2011 at 1:57 PM, Matthew Kaufman <matthew.kaufman@skype.net>
> wrote:
>> On 9/2/11 6:52 PM, Justin Uberti wrote:
>>> I'm far from sold on RTP for this, but since I think we need a sequence
>>> number (for congestion control) and a stream id (for demux), it seems we're
>>> already halfway there. Will look at the other methods - do you recall if
>>> these were mentioned in a public draft or on the mailing list?
>> There were two IDs... Cary did a presentation at the last meeting and is
>> preparing a combined draft.
>> I believe there was discussion on the list as well from some RTP folks (or
>> maybe it was just at the microphone back in Prague?) about why putting data
>> in RTP is the wrong thing.
> Thanks, will look. Main concern is how SDES-SRTP works with something
> non-RTP. Maybe that isn't supported.
> It works fine... you just take the same SDES key you stuffed in (via
> Javascript, if we don't use SDP, perhaps) and encrypt with it.

It's actually rather more complicated than this: SRTP defines a wire protocol
that is designed to be used with external key management. You'd need to
define a new wire protocol for this application, which is sort of what this
document does, but... not well.

> DTLS is even
> more obvious of course.

Indeed. Experience has shown that designing even this kind of simple security
protocol is hard. In this case it seems extraordinarily inadvisable
given that we
have a well-defined IETF Standards Track protocol designed specifically for
the purpose of securing datagram transmissions.

Received on Saturday, 3 September 2011 15:13:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:21 UTC