Re: [TLS] ESNI robustness and GREASE PRs

[David Benjamin <[e-mail]>]

On Tue, Dec 18, 2018 at 3:06 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Tue, Dec 18, 2018 at 02:27:10PM -0600, David Benjamin wrote:
> > On Tue, Dec 18, 2018 at 3:00 AM Ilari Liusvaara <
> [e-mail]>
> > wrote:
> >
> > > On Mon, Dec 17, 2018 at 05:17:37PM -0600, David Benjamin wrote:
> > > > Hi folks,
> > > >
> > > > We[*] wrote up some proposed changes for draft-ietf-tls-esni that
> we'd
> > > like
> > > > the group's thoughts on. The goal is to make ESNI more robust and
> > > eliminate
> > > > a bunch of deployment risks. The PRs are linked below:
> > > >
> > > > https://github.com/tlswg/draft-ietf-tls-esni/pull/124
> > > > https://github.com/tlswg/draft-ietf-tls-esni/pull/125
> > > >
> > > > The second recommends clients to send GREASE ESNI extensions when
> they do
> > > > not have cached ESNIKeys available. This better meets the "Do not
> stick
> > > > out" goal. The server behavior in the first PR gives us this for
> free.
> > >
> > > It seems to me that if server thinks it has ESNI enabled, but
> > > the client does not get ESNI keys for it, then all handshakes fall
> > > back to full handshake and session resumption will not work (as
> > > the server is required to reject the resumption)?
> > >
> >
> > It's possible I didn't word this correctly. If the client did not get
> ESNI
> > keys for the server, the client is presumably offering a non-ESNI
> session,
> > which has no resumption restrictions. The case we want to avoid is an
> ESNI
> > session being resumed at anything other than esni_accept. That's to cut
> out
> > the resumption case in {{verify-public-name}}. In particular, if we want
> to
> > tolerate partial rollouts where some servers don't support ESNI at all
> > while others don't at all, this scenario is a concern:
>
> "The server MUST NOT resume any sessions offered by the client that
> were established without ESNI.". This holds even if client sent a
> dummy ESNI value.
>
> > Without this case (and GREASE---see remark), we could just say servers
> MUST
> > NOT resume if they send esni_retry_request.
>
> This case the server should at least know if it has ESNI keys or not.
>
> > > Also, randomly generating the ESNI key handle does stick out, as
> > > normally the ESNI key is releatively static (DNS caching!) across whole
> > > group of domains and servers.
> > >
> >
> > This is true. I don't see a clear way around that one, short of taking
> the
> > record_digest parameter out and requiring the server do a public-key
> > trial-decrypt for each unexpired ESNI key. (Perhaps with key mismatch
> > tolerance, it's no longer necessary for servers to be quite so paranoid
> > about keeping all their old keys around, but the trial-decrypt still
> seems
> > poor.)
>
> Especially with asymmetric cryptography, as even the fastest ops are
> about 100kcyc at least (outside some very rare pieces of laptop
> hardware).
>
> > I think this is still worth doing, especially as it's basically free if
> you
> > want to support rollbacks. (Making GREASE work and tolerating
> ESNI-clueless
> > servers are very strongly related. GREASE requires that servers
> > more-or-less ignore ESNI on key mismatch.) You also need to either
> observe
> > multiple connections or know something about the server to do this.
>
> And then there might be fun with timing attacks. This is whole
> asymmetric operation, so timing signal should be rather large.
>

Sorry, that was really confusing. By "this" I meant GREASE, not trial
decryption schemes. :-)