Re: [TLS] three ECHO issues

[Christopher Wood <[e-mail]>]

On Mon, Mar 9, 2020, at 8:23 AM, Ben Schwartz wrote:
> 
> 
> 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?

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