[TLS] ESNI and Multi-CDN

[Ben Schwartz <[e-mail]>]

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.

Advantages:
 - No possibility of mixing up which ESNIKeys goes with which server IP.
 - No changes needed to recursives (which would treat the entire record as
opaque).
 - Doesn't add roundtrips at any stage.
 - Fully compatible with existing CNAME delegations.
 - Only adds complexity to the most sophisticated party (CDNs who want to
enable multi-CDN).
 - Not limited to one protocol (e.g. HTTPS).

Disadvantages:
 - IP address data is duplicated (10-100 extra bytes in the ESNI record),
and single-stack (e.g. v4-only) clients would still get both sets of IP
addresses.
 - Clients must wait for the ESNI query to complete before sending a TCP
SYN.  (Any resulting delay should be very small.  Does not apply to TFO or
QUIC.)
 - Support requires implementation work in authoritatives, especially for
load-balancing or geotargeting.
 - If IP stapling is rarely used (or rarely _not_ used), some clients might
fail to implement the rare case properly.

--Ben Schwartz, Jigsaw