I tend to agree. there's an open issue in the spec about this and I've sort of come to the conclusion that it's going to be pretty easy to determine just by sending your own ECH with the same key id and looking at what comes back.
On Mon, Mar 9, 2020 at 8:32 AM Christopher Wood <c...@heapingbits.net> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
