On 03/18/11 21:19, Glenn Maynard wrote:
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth<[email protected]> 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.)
