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

[Martin Rex <[e-mail]>]

Nico Williams wrote:
> 
> 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?

It is a design limit that should be obvious to the conscious reader
with background knowledge about cryptography.


> 
> 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.

No, you're entirely confusing things.

Independent TLS connection states (even for the same cached TLS session)
do not share traffic encryption and mac keys, so these are protected
from each other.

But when you start multiplexing adaptively chosen plaintext from
an attacker with data from a victim, then you're creating an oracle.
For TLS cipher suites using block ciphers in CBC mode, there is
a fixed encryption key for all blocks of data.  Now if the
block of data for which the attacker wants to recover the exact
plaintext is sufficiently short (e.g. DES-based = 64-bit), and this
block of contains a small amount of unknown entropy, and the attacker
is permitted sufficient guesses at the original plaintext, the attacker
may perform a guessing attempt at that unknown victim data.


> 
> > 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.

It was not a design requirement at that time, so that property does
not exist in the original SSLv3 (and TLS) design.  When cipher suites
with stream ciphers are not affected, then this is a lucky coincidence,
not a result of a conscious design (based on a requirement).


> 
> 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 every block with a known IV and known plaintext, the attacker learns
equal to the blocksize IV+plaintext pairs for a static key. (flip the
same bit in IV and plaintext and you get the same ciphertext).
For CBC, the IV is the ciphertext on the wire from the previous block
(except for the first IV on the first record in all version of TLS).


> 
> 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.

I actually feel more uncomfortable with cryptographic protocols that
are used in automated online scenarios and do not employ replay protection
(which probably means that communication with the Kerberos KDC is
 theoretically vulnerable, and what's missing is only attractive attacks
 that exploit this.)


-Martin