Draft: draft-ietf-tls-esni

Commentary: This change does the following : support for mandatory extensions , which are those that clients must process else reject the ESNIKeys record . a mandatory extension carrying a set of v4 / v6 addresses , which is effectively the combined record mode . text describing how clients ought to resolve ESNI and A / AAAA records , and use the results to initiate TLS connections . 
 That 's fair . However , it seems to be the price to get this sort of simplicity . Moreover , as an extension , it 's not pressed upon all clients for all providers . Also true ! I 'm hoping that folks who are in the position and capable of vending these records can comment on this design 's cost . 
 Given that there was no serious objection to this change and that it works for at least one operator , I 'm merging this PR . We can continue to iterate on as needed in parallel . 
 issues and advocate for the removal of the _ esni prefix . A significant side effect of that is that it becomes impossible to use a CNAME at the apex of a zone in order to refer to ESNIKeys of a server operated elsewhere . Inlining keys , as is often done with A / AAAA at the apex , is not plausible due to key rotation . The issue can largely be mitigated with the introduction of an inclusion mechanism directly in the TXT / ESNI record . 
 This should be fixed by and follow up changes . Closing as such . Please reopen if necessary ! 
 I do n't believe resolves this . 136 effectively requires the address and ESNI information to be stapled together ( which I still find objectionable ) . The issue here is that the apex can not use a CNAME to delegate to the actual third party provider 's ESNI record .. typically it just includes an A / AAAA record at the apex and hopes the pointer does n't go stale . That 's bad enough for A / AAAA but it would be terrible for ESNI because it means copying keying information and hoping it does n't go stale between two different entities . can you reopen ? 
 Sure ! Sorry for the misunderstanding . We can probably update this PR to make use of the new DNS - specific extensions . 
 Fixed by . 
 This is a substantial step in the right direction , but the fact that A / AAAA records are basically ignored makes me uneasy . The fact that A / AAAA results are essentially fully embedded would imply that all logic involved in selectively returning those responses has to be duplicated for ESNIKeys , which is also sub - optimal .
Paragraph (version A):
SNI Encryption keys can be published in the DNS using the ESNIKeys
structure, defined below.
Paragraph (version B):
Publishing ESNI keys in the DNS requires care to ensure correct
behavior.  There are deployment environments in which a domain is
served by multiple server operators who do not manage the ESNI Keys.
Because ESNIKeys and A/AAAA lookup are independent, it is therefore
possible to obtain an ESNIKeys record which does not match the A/AAAA
records.  (That is, the host to which an A or AAAA record refers is
not in possession of the ESNI keys.)  The design of the system must
therefore allow clients to detect and recover from this situation.
Paragraph (version B):
The following sections describe a DNS record format that achieve
these goals.
Paragraph (version B):
SNI Encryption keys can be published using the following ESNIKeys
structure.
Paragraph (version A):
A list of extensions that the client can take into consideration
when generating a Client Hello message.  The format is defined in
RFC8446; Section 4.2.  The purpose of the field is to provide room
for additional features in the future; this document does not
define any extension.
Paragraph (version A):
The semantics of this structure are simple: any of the listed keys
may be used to encrypt the SNI for the associated domain name.  The
cipher suite list is orthogonal to the list of keys, so each key may
be used with any cipher suite.
Paragraph (version B):
A list of extensions that the client can take into consideration
when generating a Client Hello message.  The format is defined in
RFC8446; Section 4.2.  The purpose of the field is to provide room
for additional features in the future.  An extension may be tagged
as mandatory by using an extension type codepoint with the high
order bit set to 1.  A client which receives a mandatory extension
they do not understand must reject the record.
Paragraph (version B):
The semantics of this structure are simple: any of the listed keys
may be used to encrypt the SNI for the associated domain name.  The
cipher suite list is orthogonal to the list of keys, so each key may
be used with any cipher suite.  Clients MUST parse the extension list
and check for unsupported mandatory extensions.  If an unsupported
mandatory extension is present, clients MUST reject the ESNIKeys
record.
Paragraph (version A):
Servers MUST ensure that if multiple A or AAAA records are returned
for a domain with ESNI support, all the servers pointed to by those
records are able to handle the keys returned as part of an ESNI
record for that domain.
Paragraph (version A):
Clients obtain these records by querying DNS for ESNI-enabled server
domains.  Clients may initiate these queries in parallel alongside
normal A or AAAA queries, and SHOULD block TLS handshakes until they
complete, perhaps by timing out.
Paragraph (version A):
In cases where the domain of the A or AAAA records being resolved do
not match the SNI Server Name, such as when RFC7838 Section 2.3 is
being used, the SNI domain should be used for querying the ESNI
record.
Paragraph (version B):
This section describes a client ESNI resolution algorithm using a new
"address_set" extension described below.  Future specifications may
introduce new extensions and corresponding resolution algorithms.
Paragraph (version B):
The body of this extension is encoded using the following structure.
Paragraph (version B):
A set of Address structures containing IPv4 or IPv6 addresses to
hosts which have the corresponding private ESNI key.
Paragraph (version B):
Clients SHOULD initiate ESNI queries in parallel alongside normal A
or AAAA queries to obtain address information in a timely manner in
the event that ESNI is available.  The following algorithm describes
a procedure by which clients can process ESNIKeys responses as they
arrive to produce addresses for ESNI-capable hosts.
Paragraph (version B):
CD (Connection Delay) is a configurable parameter.  The recommended
value is 50 milliseconds, as per the guidance in RFC8305.