[whatwg] PeerConnection: encryption feedback

[Ian Hickson]

On Wed, 23 Mar 2011, Harald Alvestrand wrote:
> On 03/18/11 21:19, Glenn Maynard wrote:
> > On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth<w3c at adambarth.com>  wrote:
> > 
> > > So, the salt and the nonce play different roles.  The salt is to make
> > > sure the message appears random if you haven't read the spec (and so
> > > don't know the salt).  The nonce is to prevent the attacker from
> > > crafting plaintexts that encrypt to a chosen ciphertext, even when the
> > > attacker sees both sides of the connection.  Picking a new nonce for
> > > each message means that the attack cannot choose the bytes sent on the
> > > wire.  The nonce can be communicated in-band, just like the IV for CBC
> > > mode.
> > > 
> > If you can send messages to an arbitrary IP address and port, then this
> > definitely matters: you don't want people to be able to send packets that
> > look like DNS responses to arbitrary ports, for example.  However, here the
> > communication is negotiated over STUN/TURN.  The protocol should have
> > ensured that the port you're talking to is actually expecting to receive
> > data using this protocol, and isn't, say, a DNS server.  You shouldn't be
> > able to send data at all except to a peer that agreed to receive data on the
> > port.
> > 
> > It's possible that ICE doesn't actually negotiate this securely, since the
> > STUN server itself is untrusted.  Do you (or anyone else) know if STUN
> > negotiation is secure under these circumstances?  Or do you think it doesn't
> > matter?
> The STUN server is used to obtain your own "public" IP address, for
> constructing candidate lists.
> The STUN server is not involved in the ICE handshake.
> 
> If you're using TURN relays, the TURN server is, of course, involved (it's the
> relay), but since you're trusting it to be a relay, I don't think there's an
> additional threat from the fact that it sees the ICE handshake.

Who is the "you" who is doing the trusting in this scenario?

There are a number of potential attacks here, and a number of players who 
are (or should be) all potentially mutually distrustful -- the user, the 
browser, the origin of the page, the TURN server, the remote peer, and any 
potentially victim host that has no intent in being a party to any 
communication. I haven't yet studied the threat model discussed in this 
thread in depth, but if the threat we're talking about is a cross-protocol 
attack on the potential victim host, then the TURN server can be actively 
hostile and is not trusted by the browser, and the remote peer can be 
actively hostile and is also not trusted by the browser. Obviously it's 
not a problem if the TURN server is hostile and an attack is bounced off 
the TURN server, since the TURN server could just mount the attack 
directly. The concern is presumably about whether the TURN server, the 
remote peer, and the page origin can collude to cause the browser to 
attack the victim directly.

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