Re: [TLS] ESNI robustness and GREASE PRs

[Stephen Farrell <[e-mail]>]

Hiya,

On 17/12/2018 23:17, 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

I like chunks of that. I'm unsure about others 'till I grok
'em better.

I like the bits that add detail of required behaviour, e.g.
handling resumption, which has been puzzling me:-)

The idea of a "public name" is possibly good, but I'll need
to ponder it more. (Being slow, as I am:-)

Would it be fair to say that that concept isolates ESNI from
a likely DNS ops failure mode at the expense of adding another
way in which ESNI could be defeated via abuses of the Web PKI?
If so, is there any way to make using a "public name" require
that the entity who can authenticate as the "public name" also
has the private part of the public value published in DNS?
(Apologies if your scheme does that already and I missed it, or
if that's exactly the sync breakage you're trying to mitigate;-)

At first sight though, it does look like there's an interesting
overlap between this and what Nico/Viktor were proposing about
using HRRs. (In the sense that maybe you're all heading towards
a not-bad idea, modulo what I think is ekr's winning argument
that always requiring an extra RTT would be disqualifying.)

[On a different point, changes like these (or other breaking
changes) may be easier if we do that "pick an implementation
draft" thing that's been done in other more complex cases. I'm
not sure if ESNI justifies that, but given my coding resources,
(and abilities:-) it'd help me if people wanted to do something
like that. E.g. to decide we noodle about with a -03 and try
code up to a -04 or similar (or -05 or whatever version is
appropriate). For example, there's another kind of change that
I think we want before doing interop on a later version: I'd
argue the value published in DNS needs to be DNS/zonefile friendly
and not primarily TLS-presentation-layer friendly - we're not
there now and getting there (or deciding that's not needed) may
require discussion of published drafts and not just issues/PRs.]

> https://github.com/tlswg/draft-ietf-tls-esni/pull/125

Greasing like this seems like a fine plan. I'm not sure if
greasing is still quite the appropriate term, as this is doing
more than that, but I like it lots - without something like
this ESNI will stick out a lot. I do wonder if people will
be willing to emit so many useless bytes though?

A possible alternative way to get a similar "don't stand out"
effect might be to re-do the CH changes for ESNI so that they're
encoded to look like a real key-share (maybe with some other
bits of the CH serving dual purposes) - I think that might be
just about doable, but a) likely ends up as a total hack, b) is
pretty limited (e.g. for looooong names),  and c) requires
servers to guess if a CH does or doesn't contain ESNI stuff.
Could be fun if it worked though, but has anyone looked at
that alternative way to not stand out?

Cheers,
S.

> 
> The first tries to make ESNI more robust. It introduces the notion of a
> "public name" which gives the client an authenticated signal to retry with
> new keys or without ESNI at all. This mitigates DNS/server mismatches (a
> concern on each key rotation), and partial rollouts or rollbacks (a concern
> when first enabling it, plus some scenarios with TLS-terminating
> middleboxes).
> 
> 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.
> 
> Details are in the PRs.
> 
> (The two PRs were originally written up together. I split them in two based
> on some feedback, but since they touch the same text, the GREASE PR
> includes the robustness PR. If the WG wishes to go with one but not the
> other, the text and details can be adjusted accordingly.)
> 
> Thoughts?
> 
> David
> 
> [*] Steven and I wrote the text itself, with input from Adam, Ben, and
> Brad, all CC'd.
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>