Re: [TLS] ESNI robustness and GREASE PRs

Hi David and others involved in the work,

Thank you for the PR.

2018年12月18日(火) 8:18 David Benjamin <davidben@chromium.org>:
>
> 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 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).

I think that this is a logical solution, under the premise that we
need to the fix issue.

It provides an authenticated signal, thereby protecting the
server-name from even the active attackers. That makes the SNI
exchange as secure as DoH or DoT. DNS lookup and SNI are the two
moments that we need to protect the server name, and having secure
exchange for the both is IMO the correct path.

Also, I actually like the fact that there is a non-negligible amount
of overhead in the fallback path, because that would encourage people
to deploy ESNI correctly.

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

I agree that having ESNI extension everywhere is an improvement. We
should do this regardless of if we take PR 124.

>
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
Kazuho Oku