Draft: draft-ietf-tls-esni

Commentary: … f the ESNI Keys values were present
Paragraph (version A):
This structure is placed in the RRData section of a TXT record as a
base64-encoded string.  If this encoding exceeds the 255 octet limit
of TXT strings, it must be split across multiple concatenated strings
as per Section 3.1.3 of RFC4408.  Servers MAY supply multiple
ESNIKeys values, either of the same or of different versions.  This
allows a server to support multiple versions at once.
Paragraph (version B):
This structure is placed in the RRData section of a TXT record as a
base64-encoded string.  If this encoding exceeds the 255 octet limit
of TXT strings, it must be split across multiple concatenated strings
as per Section 3.1.3 of RFC4408.  Servers MAY supply multiple
ESNIKeys values, either of the same or of different versions.  This
allows a server to support multiple versions at once.  If the server
does not supply any ESNIKeys values with a version known to the
client, then the client MUST behave as if no ESNIKeys were found.
Paragraph (version A):
"not_before" and "not_after" fields represent the validity period of
the published ESNI keys.  Clients MUST NOT use ESNI keys that was
covered by an invalid checksum or beyond the published period.
Servers SHOULD set the Resource Record TTL small enough so that the
record gets discarded by the cache before the ESNI keys reach the end
of their validity period.  Note that servers MAY need to retain the
decryption key for some time after "not_after", and will need to
consider clock skew, internal caches and the like, when selecting the
"not_before" and "not_after" values.
Paragraph (version B):
"not_before" and "not_after" fields represent the validity period of
the published ESNI keys.  Clients MUST NOT use ESNI keys that was
covered by an invalid checksum or beyond the published period.  If
none of the ESNI keys values are acceptable, the client SHOULD behave
as if no ESNIKeys were found.
Paragraph (version B):
Servers SHOULD set the Resource Record TTL small enough so that the
record gets discarded by the cache before the ESNI keys reach the end
of their validity period.  Note that servers MAY need to retain the
decryption key for some time after "not_after", and will need to
consider clock skew, internal caches and the like, when selecting the
"not_before" and "not_after" values.
Paragraph (version A):
In order to send an encrypted SNI, the client MUST first select one
of the server ESNIKeyShareEntry values and generate an (EC)DHE share
in the matching group.  This share will then be sent to the server in
the "encrypted_sni" extension and used to derive the SNI encryption
key.  It does not affect the (EC)DHE shared secret used in the TLS
key schedule.
Paragraph (version B):
In order to send an encrypted SNI, the client MUST first select one
of the server ESNIKeyShareEntry values and generate an (EC)DHE share
in the matching group.  This share will then be sent to the server in
the "encrypted_sni" extension and used to derive the SNI encryption
key.  It does not affect the (EC)DHE shared secret used in the TLS
key schedule.  It MUST also select an appropriate cipher suite from
the list of suites offered by the server.  If the client is unable to
select an appropriate group or suite it SHOULD ignore that ESNIKeys
value and MAY attempt to use another value provided by the server
(recall that servers might provide multiple ESNIKeys in response to a
ESNI TXT query).  The client MUST NOT send encrypted SNI using groups
or cipher suites not advertised by the server.