Re: [TLS] DNS-based Encrypted SNI

[Ben Schwartz <[e-mail]>]

On Mon, Jul 2, 2018 at 7:41 PM Eric Rescorla <[e-mail]> wrote:

> Hi folks,
>
> I just submitted:
>
>   https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> This draft describes a DNS-based approach to doing encrypted SNI.
>

Thanks for this proposal, Eric.  I fully support this line of work.

This proposal obviously bears some relevance to the SNI Alt-Svc + DNS
ALTSVC drafts in HTTPBIS [1][2].  That's OK; we'll sort it out eventually.
I hope people interested in this draft will also check out those.  In my
view, ESNI and those drafts are two complementary approaches to this
problem.  I can see reasons to pick one, or both, or a combination.

[1] https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02
[2] https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02

On Mon, Jul 2, 2018 at 11:59 PM Eric Rescorla <[e-mail]> wrote:

> On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters <[e-mail]> wrote:
>
...

> It is strongly recommended not to use TXT records. Why not use a new
>> RRTYPE? Everything these days knows how to serve unknown record types
>> (see RFC 3597). The only possibly exception is provisioning tools of
>> small players, but this document starts of saying you basically need
>> to be on a bulk hosting provider anyway. They can properly provision.
>>
>
> See:
>
> https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906
> <https://github..com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906>
>

That logic (CNAME compatibility) requires not placing this information at
the apex, i.e. using a prefix, as you've done.  It doesn't preclude using a
new record type.  The DNS ALTSVC draft, for example, does both.

Some other thoughts:

I expect much nitpicking of the exact DNS syntax.  You may end up wanting
to describe that separately, especially since these "introduction tokens"
may well be useful to acquire over non-DNS channels (e.g. Alt-Svc) and may
be useful for non-SNI purposes (like 0-RTT, as you've noted).

I wonder how well this scales to a "large key" future (e.g. post-quantum).

As described, this approach seems hard to use with a domain load-balanced
across two CDNs.  (I don't know how important that use case is.)

One concern I've heard many times is that we can't add non-A/AAAA queries
to a browser's critical path because there are middleboxes and buggy
recursives that will just drop them, leading to a DNS timeout delay on
every new socket.  However, for encrypted SNI I think we can ignore this by
focusing on clients with DPRIVE or DOH enabled, which should avoid these
kinds of problems.