Re: [TLS] ESNI and Multi-CDN

[Ben Schwartz <[e-mail]>]

On Tue, Dec 18, 2018 at 4:55 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Tue, Dec 18, 2018 at 04:26:45PM -0500, Ben Schwartz wrote:
> > On Tue, Dec 18, 2018 at 4:14 PM Ilari Liusvaara <
> [e-mail]>
> > wrote:
> >
> > > On Tue, Dec 18, 2018 at 12:29:56PM -0500, Ben Schwartz wrote:
> > > > I'd like to propose a solution to the ESNI + Multi-CDN problem
> (which has
> > > > been discussed a lot on this list already).  My suggestion is that we
> > > > define the ESNI DNS record format as optionally including "stapled"
> > > A/AAAA
> > > > records.
> > > >
> > > > Server operators would have the option to publish an ESNI record that
> > > only
> > > > contains an ESNIKeys structure (like the current TXT record), or to
> > > publish
> > > > an ESNI record that also includes IPv4 and/or IPv6 addresses.  (A
> > > > Sufficiently Advanced authoritative DNS server would generate such
> > > records
> > > > automatically.)  This kind of address stapling would only be
> required of
> > > > CDN operators who want to support multi-CDN deployments.
> > > >
> > > > Clients would issue A, AAAA, and ESNI queries in parallel (as with
> the
> > > > current TXT record).  If an ESNI record exists, and it contains IP
> > > > addresses, the client discards the results of the A or AAAA query.
> > >
> > > I do not think this will work:
> > >
> > > - The CDNs need control of ESNIkeys
> > > - If you hand them this control, you can hand over address control at
> > >   the same time.
> > > - Now you are in HTTP service discovery territory.
> > >
> > > I am not saying that HTTP service discovery is undesirable (it is one
> > > of those perennial topics that are not seemingly bad ideas but never
> > > seem to get done).
> > >
> >
> > Sorry, I don't understand.  What are you saying will not work?
> >
> > This proposal is not HTTP-related, nor is it any kind of service
> > discovery.  A CDN necessarily controls both the addresses and ESNIKeys;
> > this proposal just stores that info in one RR instead of two.
>
> What I meant is that one must be able to redirect the ESNI lookup
> somehow to the CDN itself. Otherwise updating the ESNI keys is too
> hard due to excessive coordination required. And if you can somehow
> redirect the ESNI lookup, you could redirect the address lookup using
> the same mechanism.
>

Yes.  This proposal assumes that these lookups are in fact the same, i.e.
they are both for the same name (www.example.com), and this entire name is
redirected (i.e. delegated) to the CDN via CNAME (which is not
type-specific).  This is the typical deployment pattern for CDN customers.


> And what that results is a service discovery mechanism.


No, it's just CNAME.


> And turns
> out that HTTP is pretty much the only widely used protocol that does
> not have service discovery mechansim (e.g., SMTP uses MX, XMPP uses
> SRV, etc..).
>
>
>
> -Ilari
>
>
>