Re: [TLS] three ECHO issues

[Ben Schwartz <[e-mail]>]

On Mon, Mar 9, 2020 at 6:49 AM Stephen Farrell <[e-mail]>
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?


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