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. > 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. For most other outer CH extensions, I expect values would have little or no effect really, as the client should either give up or try again with new ESNI public keys, but that might not be true of QUIC stuff - any idea? Anyway, if the consensus ends up to be to code up a fully flexible outer CH, then I'll try do that, but I'd love to hear that others have looked at their code and (still) figure that's a good plan. Cheers, S. > > -- Christian Huitema > >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
