Re: [TLS] Rizzo claims implementation attach, should be interesting

[Nico Williams <[e-mail]>]

On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <[e-mail]> wrote:
>> SSL was NEVER designed with a promise that you could multiplex
>> data from an evil attack with data from a victim over the very same
>> SSL connection and be secure against adaptive chose plaintext
>> attacks trying to recover data from the victim.

I wasn't there.  I don't know what it was designed for.  But here's
the thing: why shouldn't the designers have assumed that some of the
data sent over SSL might be untrusted?  On what grounds would it have
been OK to say "no untrusted data, please"?  And where was this
restriction documented?

But let's grant that restriction.  That would have meant that we
should never have allowed IMAP over SSL, for example, and taking the
argument to extremes, we should never have allowed HTTP POST over SSL
either.

This is really Marsh's point, I think, and I agree with it.

> SSL came before Javascript and even before cookies. So this is certainly
> outside the model.
> Adding AES in CBC mode probably came after the model had been changed
> though.

Yeah, sure, but I think it's fairer to say that the subject probably
didn't come up, not that SSL was not intended for this.

> If we want to avoid this type of attack we should probably change the
> encryption mode. I don't like stream ciphers in general, but SSL was
> designed round one and has been extensively verified when a stream cipher is
> used.
> From a design point of view, re-use of the same key to encrypt each block is
> bad news and turning a block cipher into a stream cipher is bad news. Anyone
> know why CBC is so popular vs PCBC?

Block ciphers in counter mode are as broken in the face of key&IV
reuse as any stream cipher, and for the same sorts of reasons.  This
is not a reason to not use counter modes.  It's a reason to use them
with care.

For example, in a situation like Kerberos' PDUs counter modes are
dangerous because there's no "connection" context for most of those
PDUs, thus no way to prevent key&IV reuse.  But for TLS, and even
DTLS, there's no such issue.

Nico
--