[whatwg] PeerConnection: encryption feedback

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.

(The password in an ICE handshake is never passed across the wire - only 
a hash of the packet + the password is passed.)

Received on Wednesday, 23 March 2011 15:25:19 UTC