Re: [TLS] An SCSV to stop TLS fallback.

[[e-mail] (Martin Rex)]

Watson Ladd wrote:
> Martin Rex <[e-mail]> wrote:
>>
>> Btw. AES128-CBC-SHA1 is more secure than AES128-GCM/-CCM, so the only
>> thing the client might be "loosing" is a little performance, and
>> that AEAD can not currently be negotiated and used unless
>> ClientHello.client_version is set to { 0x03, 0x03 } is a silly defect
>> of the specification(s) that could be easily fixed.
>>
>> I am assuming you are discussing the modes as specified and
>> implemented in TLS? In that case you are dead wrong.
>> Lucky 13, BEAST, and even if we drop all that no protocol depending
>> both on SHA1 and AES can be stronger than one depending
>> on AES alone.
>>
>> Lucky 13 and BEAST are completely irrelevant for the majority
>> of usage scenarios, and there's even a simple 1/(n-1) record splitting
>> workaround for BEAST for those with paranoia.
>
> Paranoia is a requirement for this WG.

TLSv1.1 and TLSv1.2 seem to have been developed without paranoia.

The attack surface provided by mac-pad-encrypt rather than the
obvious fix pad-mac-encrypt, which Lucky 13 exploited, was clearly
pointed out by Serge Vaudenay in 2001, but completely ignored by
the TLS WG in 2006 (TLSv1.1) and again in 2008 (TLSv1.2).

Replacing the (rsa,md5+sha1) digitally-signed from SSLv3->TLSv1.1 with
(rsa,sha1) or (rsa,md5) in TLSv1.2 is huge degradation in security,
certainly nothing that someone with paranoia would do. 


>
> > I don't know what you mean by "AES alone", but if you are refering
> > to "AES-GCM", that isn't AES alone, but AES in combination with GHASH,
> > and HMAC-SHA1 beats the security of GHASH by a huge safety margin.
>
> No, GHASH has an unconditional security guarantee, while HMAC is only
> conjectured to be secure.

If that were a real concern, then you would have to violently
oppose to Peter's (and other folks) suggestion to change
from mac-pad-encrypt to pad-encrypt-mac (aka EtA).

>
> If you break AES-GCM you break AES, and hence AES-CBC-SHA1.
> AES-CBC-SHA1 also falls if
> HMAC fails.

Currently HMAC-SHA1 in TLS is protected by AES CBC encryption,
so it is simply impossible to attack HMAC-SHA1 without first breaking AES.

In contrast to AES-GCM, you can not target and flip individual bits
of the MAC'ed plaintext from AES-CBC-SHA1 nor can you target and flip
individual bits from the HMAC-SHA1 output.  You actually do not not
anything about what goes in and what comes out of HMAC-SHA1 right now.


-Martin