[whatwg] PeerConnection: encryption feedback

[Glenn Maynard]

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?

I don't mean to harp on this, but an additional 16 bytes of nonce per packet
is significant for small payloads, so if it's necessary I'd like to
understand why.

> Oh, right--AES-128-CTR needs multiple counter values to encrypt a full UDP
> > packet.  That means the actual counter value in my scheme would look like
> > "packet-counter-value << 16 | offset-in-packet".  The particulars of the
> > AES-128-CTR algorithm should be defined--the NIST reference only defines
> AES
> > itself, not the CTR mode.  It also needs to specify a padding method, eg.
> > PKCS7 or ANSI X.923, to pad to AES's block size of 16 bytes.  (Again,
> > though, these are all well-invented wheels...)
>
> Yep.
>
> Adam
>

Actually, I was wrong about padding: it's a CBC thing, CTR doesn't need it.
With CTR, the length of the ciphertext determines the length of the
plaintext directly.

-- 
Glenn Maynard