[whatwg] Peer-to-peer communication, video conferencing, and related topics (2)
ian at hixie.ch
Tue Mar 29 10:50:52 PDT 2011
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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg