[whatwg] PeerConnection: encryption feedback

[Adam Barth]

On Thu, Mar 17, 2011 at 9:24 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Thu, Mar 17, 2011 at 11:07 PM, Adam Barth <w3c at adambarth.com> wrote:
>>> But you get this with a per-connection (not per-packet) nonce and CTR's
>>> sequence number.  You don't need a unique 16-byte nonce for each packet.
>>
>> The attacker observes each packet once delivered, so you need a new
>> nonce for each packet.
>
> I think you're talking about the attack described in
> http://www.openssl.org/~bodo/tls-cbc.txt.  These attacks are against CBC,
> the cipher mode used by TLS block ciphers.  That's why TLS 1.1 includes a
> separate IV for each packet.  That sort of attack doesn't apply to the CTR
> cipher mode, because the contents of blocks don't feed back into the
> encryption as they do with CBC.
>
> If each packet does have its own random IV, then the CBC cipher mode should
> be used, not CTR.  There may be other reasons to use CBC, as it's used by
> both TLS and IPsec, but if so I don't know what they are.

Nope.  I'm not referring to that attack.  To be precise, the required
property is that each byte on the wire, when viewed independently of
the other bytes, appears to be chosen uniformly at random from the
point of view of the attacker when the message leaves the user agent.

>> Then the MAC would fail because we're using encrypt-then-mac.
>
> That works if the MAC includes the entire packet, including not just C (the
> encrypted data) but also the packet headers (the sequence number).

Correct.

Adam