Re: [TLS] three ECHO issues

[Ilari Liusvaara <[e-mail]>]

On Sun, Mar 08, 2020 at 07:13:05PM -0700, Christian Huitema wrote:
> On 3/8/2020 10:14 AM, Stephen Farrell wrote:
> 
> > I'm questioning whether that's a good goal or not. In my
> > analysis of the various extensions, only SNI and ALPN seem
> > to offer immediate value.
> 
> Uh, No. First, we do have fingerprinting attacks that look at the
> pattern of extensions. If the extensions are encrypted in the ESNI, they
> cannot do that. And then, we have extensions that reveal a lot about the
> app, like for example the QUIC parameters extension. Those are just as
> sensitive as the ALPN.

The extensions Stephen was complaining about are related to "crypto-
graphic context". And these extensions differing in meaning across
the two client hellos seems like asking for trouble to me. There are
some harmless differences tho, e.g., omitting some banned in TLS 1.3
group from inner supported_groups.

These extensions are the ones that are valid in HRR or SH (except
tls_cert_with_extern_psk, which is not cryptographic context despite
being in SH), plus a few others (supported_groups, record_size_limit,
psk_key_exchange_modes). Also included is non-extension ciphersuite
list.

Then there is the special snowflake that is pre_shared_key. One
wants both inner and outer pre_shared_key to have the same number of
PSKs, with the same associated hash functions (if the PSKs are real at
all). But obviously binders have to differ.

Intuitive rule would be for servers to establish cryptographic context
before even looking at ECHO. And then if the front server determines
that split mode should be used, forward to/from back server, at which
point the decisions on cryptographic context are just moot (and the back
server does its own cryptographic context based on inner client hello).

Unfortunately I suspect that would not actually work due to PSKs. A
shared-mode server sees PSK that can be resumed and then resumes it.
Now what if the inner client hello contains SNI which is unknown?
I suspect pretending that ECHO did not exist would be the best
option.

And there are more annoying corner cases:

What keys would be used for 0-RTT? Inner and outer client hello gives
different 0-RTT keys, even if all cryptographic context is as same as
possible.

And how is lame (misconfiguration) back server supposed to reject
the forwarded connection? Plaintext unrecognized name alert?


-Ilari