Re: [TLS] ESNI robustness and GREASE PRs - client tracking concerns?

[David Benjamin <[e-mail]>]

On Tue, Dec 18, 2018 at 1:27 AM Viktor Dukhovni <[e-mail]>
wrote:

> On Tue, Dec 18, 2018 at 12:45:22AM -0600, David Benjamin wrote:
>
> > An earlier iteration even placed the retry on the same connection, which
> > makes the analog clearer.  (Doing it in the same connection is rather a
> > mess, so we bounce to a new one.)
>
> Any concern about the possibility that the reason the key did not
> work was that the particular server had unexpected keys, but
> reconnecting might land on a different server, with yet another set
> of keys?  (Which is to say that I am concerned, but perhaps you're
> not?).
>

That's a good point. This probably means the client needs to allow for a
handful of iterations before giving up, which is a bit of a nuisance.


> Also connection re-establishment has considerable cost, additional
> TCP roundtrips on top of the extra TLS roundtrips.
>

Agreed. The other cost is that it cannot be implemented entirely within the
TLS stack, since most TLS stacks do not establish connections. (Though ESNI
already needs caller involvement anyway to get the ESNI keys out of DNS,
and the perf overhead can be fine if you believe it's rare.)

Is the HRR idea being explored in the parallel thread not viable?
> [ That'd be fine by me, one less thing to worry about, but it did
> seem worth exploring at first blush...  The suggestion of using it
> as a fallback when there are either no keys in DNS, or they don't
> work also seems like it could be viable. ]
>

I actually still need to fully digest in that thread. I hadn't even
realized when I sent this how much the two had in common, or I would have
acknowledged it in the mail. Sorry about that. I imagine my email probably
looked odd to you. I'm glad to see we had similar ideas!

There might be some version that works? We never came up with a formulation
we really liked, and the single-connection version made a lot of things
simpler. Some of the nuisances with doing it together:

- Sticking two full handshakes on the same connection introduces several
new key changes, which will frustrate QUIC and DTLS.

- Joining two handshakes at the ServerHello or so frustrates existing
analysis, split mode, and any servers with SNI-dependent cipher parameters.
(Everyone seems to keep asking their hosting providers for silly little
checkboxes to configure TLS parameters.)

David