Re: [TLS] ESNI robustness and GREASE PRs

[David Benjamin <[e-mail]>]

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:

1. Server A does ESNI. Server B does not.
2. Client gets ESNIKeys from DNS and talks to server A. ESNI works out and
all. It gets a session for origin-name.
3. Client connects again and this time load balances to server B. Or maybe
server B is server A at a later time. Perhaps the ESNI implementation had a
show-stopping bug and folks had to revert for now. It will send
SNI=public-name, ESNI=origin-name, PSKs=ticket-for-origin-name.

Since server B has no clue what's going on, it'll ignore the ESNI
extension, and then process SNI + PSKs. This runs into the mess of
cross-name resumption stuff. In particular, RFC 8446 says:

   Clients MUST only resume if the new SNI value is valid for the server
   certificate presented in the original session and SHOULD only resume
   if the SNI value matches the one used in the original session.  The
   latter is a performance optimization: normally, there is no reason to
   expect that different servers covered by a single certificate would
   be able to accept each other's tickets; hence, attempting resumption
   in that case would waste a single-use ticket.  If such an indication
   is provided (externally or by any other means), clients MAY resume
   with a different SNI value.

It is not possible for the client to honor that first sentence because it
is effectively offering two names at once, so it does not know which name
the server will use to handle the ticket. This is kind of a headache. The
ESNI bit in the session disambiguates by preventing the server from
resuming under the SNI name. The semantics are: this session is associated
with the ESNI name, not the SNI name. If you don't know what that means, or
if you can't decrypt the ESNI name, please ignore it.

Without this case (and GREASE---see remark), we could just say servers MUST
NOT resume if they send esni_retry_request.


> 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.)

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.

David