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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
