- From: Eric Rescorla <ekr@rtfm.com>
- Date: Sat, 3 Sep 2011 08:10:48 -0700
- 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. -Ekr
Received on Saturday, 3 September 2011 15:13:28 UTC