[whatwg] Peer-to-peer communication, video conferencing, and related topics (2)

On Mar 29, 2011, at 3:00 AM, Ian Hickson <ian at hixie.ch> wrote:

> 
> 
> On Thu, 24 Mar 2011, Matthew Kaufman wrote:
>> 
>> That goal is incompatible with legacy interoperability.
> 
> There is no legacy when it comes to UDP data media streams. This is a new 
> protocol, no existing servers implement it.
> 
> 

Disagree. IF we specify that the media is sent using RTP/SRTP (noting the requirement for a handshake to ensure a willing recipient) then quite a few existing endpoints (SIP phones on desks, PSTN gateways) can talk directly to/from browsers. This is a significant advantage.

If instead the media is wrapped in (for instance) a masking layer, this chance for direct peer-to-peer interoperability is lost.

> 
> 
> On Wed, 23 Mar 2011, Matthew Kaufman wrote:
>> 
>> I'd go one further... why not DTLS-SRTP for the media and DTLS with some 
>> other header shim for the data messages?
> 
> The spec doesn't say what should happen for the media; that's left up to 
> the UAs to negotiate via SDP offer/answer (as done by ICE).

But see above... We don't get interop if the (S)RTP is inside something else.

> Regarding DTLS 
> around a shim for the data messages, DTLS seems inappropriate for the 
> reasons discussed earlier in this reply.

Also disagree, see below.

> 
> 
>> In particular, there are significant security advantages to end-to-end 
>> keying rather than transmitting keys over the signaling channel.
> 
> Could you elaborate on these?
> 
> 

End-to-end keying (see my earlier refs to the DTLS-SRTP RFCs) gives you significantly greater privacy for the media (because the web service doesn't know the negotiated key), including the possibility for perfect forward secrecy for these channels.

DTLS also builds in existing, vetted security mechanisms instead of rolling something new from scratch.

I have previously shown why an optional API for forcing keys would be advantageous. (legacy interop with SDES-keyed SRTP, and some multi-party cases)

Matthew Kaufman
(sent from my iPhone)

Received on Tuesday, 29 March 2011 00:46:58 UTC