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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
