On Mon, Mar 9, 2020, at 8:23 AM, Ben Schwartz wrote: > > > On Mon, Mar 9, 2020 at 6:49 AM Stephen Farrell > <stephen.farr...@cs.tcd.ie> wrote: > > > > Hiya, > > > > On 09/03/2020 02:13, 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. > > > > Well... that depends on whether or not the outer CH that > > includes the inner exposes fingerprintable detail. If it > > were possible to define a minimal outer CH profile that > > everyone could use, then I'd be for that, but not sure > > it's feasible. > > Instead of one profile for "everyone", the ECHOConfig could provide > instructions for forming the ClientHelloOuter. > > BTW, enumerating the supported ALPNs in the ECHOConfig would solve the > ALPN padding problem (but now we're awfully close to cTLS...). > > > > 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. > > > > Wasn't in the OpenSSL code I looked at:-) But sure, if > > there are others that offer immediate value, good to know > > about 'em. What's a good ref for that? (I've not been > > keeping up to date with QUIC-detail.) > > > > The main problems I've seen in inner/outer variance > > so far relate to the TLS key share though - because > > that (and associated values) generate loads of internal > > state that has to be duplicated and that can have a > > bunch of hard to track side-effects in the code when > > the trial decryption is being checked. > > It seems like trial decryption can be avoided by tagging the > ServerHello. For example, the client could include X random bytes in > the ClientHelloInner, and the server could echo them in cleartext if > ECHO is in use, or send X random bytes if ECHO decryption failed. (The > extra upstream bytes can probably be avoided by returning a hash of the > nonce or something.) Would this make implementation easier?
We might also consider dropping the "do not stick out" requirement altogether. That would make this much simpler: just put a flag in SH. Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
