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

[Ian Hickson]

On Tue, 29 Mar 2011, Matthew Kaufman wrote:
> 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.

Sure. The spec currently doesn't say what happens with the audio/video 
media at all; if browsers implement the same media transports as existing 
legacy devices then we get interop essentially for free (assuming a 
gateway for the signaling channel).


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

The masking layer isn't used for the audio/video data. It's just for the 
game data, which is a new protocol.


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

For audio/video media, sure (though note that the Web page has access to 
record the data on either end, so the privacy is limited to whether the 
UA allows the user to control whether recording works or not). But for the 
data UDP media channel there is no privacy gain here, since all the data 
is generated by the Web service in the first place.


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

We have to balance the benefit of having something really simple against 
the benefits of having something already vetted. Also, it is dangerous to 
assume that something already vetted is automatically fine in a Web 
browser environment. For example, most existing protocols are vetted on 
the assumption that the local client is trusted, sicne if the local client 
wasn't trusted it could send out any arbitrary packets it wanted over the 
network. This assumption doesn't hold in a Web browser environment, where 
the local client is split into two parts, one of which is trusted and 
implements the protocol, but the other of which can be actively hostile 
and provides all the inputs to the protocol.

With the data UDP media stream protocol, the security aspects are 
reasonably easy to reason about, so it should be straight-forward to 
evaluate even though it is a new formulation. Also, it reuses existing 
well-understood techniques in a straight-forward way, which also helps.


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

I apparently missed that; if you could point me to your earlier mail or 
reiterate the salient points for this that would be great.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'