Re: [TLS] RFC4492bis - Removing ECDH

[Michael Clark <[e-mail]>]

On 11/1/15 1:14 pm, Ilari Liusvaara wrote:
> On Sun, Jan 11, 2015 at 10:17:09AM +0800, Michael Clark wrote:
>>
>> There is a more subtle pass through case where handshake messages can be
>> tampered with (without access to a CA, just an Internet coffee bucks
>> WiFi tap). Allows attacks such as editing cipher lists and any other
>> associated handshake metadata (curve format extensions, switching on
>> compression) that are not properly authenticated. Until I am certain
>> they are completely mitigated I remain skeptical.
> 
> This attack won't work.
> 
> - TLS 1.3: The messages are hashed into hMS, so you can't decrypt the
>   rest of the handshake due to having wrong keys.

This was my thinking however I could not read this clearly in the text
as the record protection for handshake was stated as NULL NULL AEAD.

I am still looking for clear text in {{key-calculation}} that describes
that a strong authenticator of all sent handshake messages are returned
to each end signed in the Finished message.

Can we differentiate a tamper from garbled data?

Anyway it offers no protection against the yellow patch cable to the
grey box. There are many CA certs in the vendor trust stores. If you
sent 3 certs from CAs with no relationships then you could eliminate
this kind of tampering. multi-rooted. Verify is only a cost for 24H
(given session caching and ticket timeout is sorted).

> - TLS 1.0-1.2 w/o false start: The Finished values will fail to verify.
> - TLS 1.0-1.2 /w false start: The selected crypto must be strong, or
>   endpoints won't enage in false start.

OK In TLS 1.2 the spec states there is no record protection for
handshake messages. I see verify_data field in Finished. It is vaguely
specified in RFC5426 and RFC5288 (AES-GCM) makes no reference to it.

However I am still skeptical as there is no record protection for
handshake messages so I don't know what is preventing the proxy from
returning illegal_parameter to the client hello until the client does a
TLS1.0 ClientHello and then edit the cipher list remove SCSV and cause
client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

I'm trying to find where the 12 octect verify_data is specified. If
*all* of the the handshake payload is in a MAC in verify data then you
could generate still generated ignored extensions to get a 96-bit hash
collision. Still reasoning about it...

Michael