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

[Nico Williams <[e-mail]>]

On Tue, Sep 20, 2011 at 4:31 PM, Martin Rex <[e-mail]> wrote:
> 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.

It's been roughly two decades, and only now did this get noticed.  And
there are many experts who've worked on TLS and apps that use it.

Undocumented design limitations are not obvious, even if in retrospect
they should have been.

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

I said nothing about sharing of keys across connections.  I did not
even imply it.

> But when you start multiplexing adaptively chosen plaintext from
> an attacker with data from a victim, then you're creating an oracle.

Multiplexing?  Just mixing will do.  IMAP lets you... read emails from
untrusted sources (e.g., spam), as well as ones from trusted sources.
Oops.  This is silly.

Nico
--