jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-esni

Commentary: The TLS server name ( and thus SNI ) is the HTTP origin name , however it is not necessarily the same as the host name of the TLS server . HTTP Alternative Services is the obvious way that happens - but    never changes the origin name . When fetching the ESNI key , do we fetch it from or I think origin - name makes more sense - keeping everything that is an expiicit protocol element in terms of origin eliminates confusion . the counter argument is that you can use alt - svc to do fine grained fanout to providers with different keys ( using cdn specific names for them in alt - svc ) in a way that is harder to do through the origin name dns controls . 
 My view is that the base name that is used to lookup the ESNI value ( i.e. the name excluding the prefix ) must be the same as the hostname that is carried by the ESNI extension . ESNI is a replacement for SNI , and I think that the design should allow the TLS stack to obtain the ESNI key by itself ( i.e. by querying ) . 
 PS . To give an example , golang 's TLS API to establish a new connection looks like below . As is obvious from the example , name resolution happens inside the TLS stack . I 'd assume that we would want to handle ESNI record lookup within the stack as well . Therefore , the name used to lookup the ESNI record can not be the origin name , which is specific to the behavior defined in HTTP ( alt - svc ) , which operates above the TLS stack . It needs to be the hostname that is used for the name resolution ( or a name that is derived from that ) . My understanding is that TLS stacks on other programming language often has the same abstraction ; i.e. handle name resolution inside in the TLS connection establishment call ( or the TCP connection establishment call ) . 
 This matches my opinion , and also what firefox nightly is currently doing .. but I 'm confused by your next comment afaict the SNI information actually comes from tls .  ( Falling back to only if not provided ) .. this is no doubt also the information used to authenticate the cert .. The TLS stack is going to need both pieces of information . So which should it use ? no - the origin name is the SNI name even with alt - svc . It might not be the host name . If a stack ca n't support alt - svc , then this is n't a problem - the name is the same everywhere :) If a stack does support alt - svc then it has 2 names to deal with .. one is the name used for SNI and auth , and the other is the one used for TCP . ( or perhaps it does n't do TCP on its own ) . All this issue is trying to do is decide whether the name we lookup for ENSNI / TXT is the same as the name we lookup for A / AAAA .. I 'm going to say that they do n't necessarily have to match . ( i.e. your A could be for the alt - svc but your txt / esni is always going to be for the origin - which is the same thing you put in your CH . I 'll make a pr .
Paragraph (version B):
In cases where the domain of the A or AAAA records being resolved do
not match the SNI Server Name, such as when RFC7838 is being used,
the SNI domain should be used for querying the ESNI TXT record.
Draft: draft-ietf-tls-esni

Commentary: Discussed offline .
Paragraph (version A):
If the decrypted value's length is different from the advertised
ESNIKeys.padded_length or the padding consists of any value other
than 0, then the server MUST abort the connection with an
illegal_parameter alert.  Otherwise, the server uses the
PaddedServerNameList.sni value as if it were the "server_name"
extension.  Any actual "server_name" extension is ignored.
Paragraph (version B):
If the decrypted value's length is different from the advertised
ESNIKeys.padded_length or the padding consists of any value other
than 0, then the server MUST abort the connection with an
illegal_parameter alert.  Otherwise, the server uses the
PaddedServerNameList.sni value as if it were the "server_name"
extension.  Any actual "server_name" extension is ignored, which also
means the server MUST NOT send the "server_name" extension to the
client.
Draft: draft-ietf-tls-esni

Commentary: what do you think ? 
 : +1 :
Paragraph (version A):
The first four (4) octets of the SHA-256 message digest RFC6234 of
the ESNIKeys structure starting from the first octet of "keys" to
the end of the structure.
Paragraph (version B):
The first four (4) octets of the SHA-256 message digest RFC6234 of
the ESNIKeys structure.  For the purpose of computing the
checksum, the value of the "checksum" field MUST be set to zero.
Draft: draft-ietf-tls-esni

Commentary: Do we need it . 
 For  ( the DNS record ) I do not think we need a version for the following reasons : I think we would prefer adding extensions rather than making incompatible changes we always have the freedom to pick a new prefix ( e.g. ) or a new RR type when making incompatible changes an incompatible change will require the client to query for two DNS records anyways For the ESNI extension , I also do not think that we need a version field . When we define an extension sometime in the future , we could the advertise the support as an extension in the ESNIKeys to instruct the clients that support that extension to send a CH extension that uses a different extension ID than the ESNI extension . 
 A lot of other TXT records have a version in them . It turns out that if you do that you can query for TXT records and get multiple answers back . Then , you pick those with the version you like . That 's one query . I 'm tempted to suggest that the first octet ( or two ) be used for a version number . It 's cheap . 
 I 'm concerned about how we iterate on these in the field . They 're not tied to TLS version , so what if we decide to change the formats , as we are discussing in 
 a magic number ( including version ) is a pretty decent idea . right now _ esni is in its own namespace but you can imagine someone doing a txt record that applies to every dns response so we would want to disambiguate that as well . take note to update the " concat multiple records " rule if we go down this path .. 
 I think that having version is a good idea in sense that it allows to do experiments before the standardization completes .
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.
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.
Draft: draft-rescorla-tls-esni

Commentary: please have a look ! 
 The order of DNS queries may matter in systems that use Happy Eyeballs . Also , should TLS connections block until ESNI key queries come back ? What if they never come back ? 
 can you elaborate on what you 're thinking about wrt he ? ( assuming the plan is off the table ) 
 Basically addressed in .
Paragraph (version A):
Clients obtain these records by querying DNS for ESNI-enabled server
domains.  Thus, servers operating in Split Mode SHOULD have DNS
configured to return the same A (or AAAA) record for all ESNI-enabled
servers they service.  This yields an anonymity set of cardinality
equal to the number of ESNI-enabled server domains supported by a
given client-facing server.  Thus, even with SNI encryption, an
attacker which can enumerate the set of ESNI-enabled domains
supported by a client-facing server can guess the correct SNI with
probability at least 1/K, where K is the size of this ESNI-enabled
server anonymity set.  This probability may be increased via traffic
analysis or other mechanisms.
Paragraph (version B):
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 B):
Servers operating in Split Mode SHOULD have DNS configured to return
the same A (or AAAA) record for all ESNI-enabled servers they
service.  This yields an anonymity set of cardinality equal to the
number of ESNI-enabled server domains supported by a given client-
facing server.  Thus, even with SNI encryption, an attacker which can
enumerate the set of ESNI-enabled domains supported by a client-
facing server can guess the correct SNI with probability at least 1/
K, where K is the size of this ESNI-enabled server anonymity set.
This probability may be increased via traffic analysis or other
mechanisms.
Draft: draft-rescorla-tls-esni

Commentary: LGTM .
Paragraph (version A):
This value consists of the serialized ServerNameList padded with
enough zeroes to make the total structure ESNIKeys.padded_length
bytes long.  The purpose of the padding is to prevent attackers from
using the length of the "encrypted_server_name" extension to
determine the true SNI.  If the serialized ServerNameList is longer
than ESNIKeys.padded_length, the client MUST NOT use the
"encrypted_server_name" extension.
Paragraph (version B):
This value consists of the serialized ServerNameList from the
"server_name" extension, padded with enough zeroes to make the total
structure ESNIKeys.padded_length bytes long.  The purpose of the
padding is to prevent attackers from using the length of the
"encrypted_server_name" extension to determine the true SNI.  If the
serialized ServerNameList is longer than ESNIKeys.padded_length, the
client MUST NOT use the "encrypted_server_name" extension.
Draft: draft-rescorla-tls-esni

Commentary: I 'm not sure this is much better . I would changes the " Note that servers ... " sentence to something like : 
 See
Paragraph (version A):
The "checksum" field provides protection against transmission errors,
including those caused by intermediaries such as a DNS proxy running
on a home router.  "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.
Paragraph (version A):
Client MAY cache the ESNIKeys for a particular domain based on the
TTL of the Resource Record, but SHOULD NOT cache it based on the
not_after value, to allow servers to rotate the keys often and
improve forward secrecy (due to clock skew on the client, it may not
be possible for the server to use a very short key lifetime).  Note
that servers will need to retain the decryption key for some time
after not_after to deal with clock skew, internal caches, and the
like.
Paragraph (version B):
The "checksum" field provides protection against transmission errors,
including those caused by intermediaries such as a DNS proxy running
on a home router.
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.
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 will need to retain the
decryption key for some time after "not_after" to deal with clock
skew, internal caches, and the like.
Paragraph (version B):
Client MAY cache the ESNIKeys for a particular domain based on the
TTL of the Resource Record, but SHOULD NOT cache it based on the
not_after value, to allow servers to rotate the keys often and
improve forward secrecy.
Draft: draft-rescorla-tls-esni

Commentary: " padding_length " appears out of nowhere and is not defined .
Paragraph (version A):
If the decrypted value's length is different from the advertised
padding_length or the padding consists of any value other than 0,
then the server MUST abort the connection with an illegal_parameter
alert.  Otherwise, the server uses the PaddedServerNameList.sni value
as if it were the "server_name" extension.  Any actual "server_name"
extension is ignored.
Paragraph (version B):
If the decrypted value's length is different from the advertised
ESNIKeys.padded_length or the padding consists of any value other
than 0, then the server MUST abort the connection with an
illegal_parameter alert.  Otherwise, the server uses the
PaddedServerNameList.sni value as if it were the "server_name"
extension.  Any actual "server_name" extension is ignored.
Draft: draft-rescorla-tls-esni

Commentary: Thank you for the changes . It 's super clear to me now .
Paragraph (version B):
First four (4) octets of the SHA-256 message digest RFC6234 of the
ESNIKeys structure starting from the first octet of "keys" to the
end of the structure.
Paragraph (version B):
The length to pad the ServerNameList value to prior to encryption.
This value SHOULD be set to the largest ServerNameList the server
expects to support rounded up the nearest multiple of 16.  If the
server supports wildcard names, it SHOULD set this value to 256.
Paragraph (version A):
Assuming that these checks succeed, the server then computes K_sni
and decrypts the ServerName value.  If decryption fails, the server
MUST abort the connection with a "decrypt_error" alert.
Paragraph (version A):
In comparison to I-D.kazuho-protected-sni, wherein DNS Resource
Records are signed via a server private key, ESNIKeys have no
authenticity or provenance information.  This means that any attacker
which can inject DNS responses or poison DNS caches, which is a
common scenario in client access netowrks, can supply clients with
fake ESNIKeys (so that the client encrypts SNI to them) or strip the
ESNIKeys from the response.  However, in the face of an attacker that
controls DNS, no SNI encryption scheme can work because the attacker
can replace the IP address, thus blocking client connections, or
substituting a unique IP address which is 1:1 with the DNS name that
was looked up (module DNS wildcards).  Thus, allowing the ESNIKeys in
the clear does not make the situation significantly worse.
Paragraph (version B):
In comparison to I-D.kazuho-protected-sni, wherein DNS Resource
Records are signed via a server private key, ESNIKeys have no
authenticity or provenance information.  This means that any attacker
which can inject DNS responses or poison DNS caches, which is a
common scenario in client access networks, can supply clients with
fake ESNIKeys (so that the client encrypts SNI to them) or strip the
ESNIKeys from the response.  However, in the face of an attacker that
controls DNS, no SNI encryption scheme can work because the attacker
can replace the IP address, thus blocking client connections, or
substituting a unique IP address which is 1:1 with the DNS name that
was looked up (module DNS wildcards).  Thus, allowing the ESNIKeys in
the clear does not make the situation significantly worse.
Draft: draft-rescorla-tls-esni

Commentary: Also see 
 LGTM -- thanks ! 
 I suggest dropping the references to  's individual alt - svc in DNS draft .. it has n't been adopted and its future is murky . actual alt - svc ( the non dns kind ) actually requires the use of the plaintext SNI . As those are both cachable and connections to new IP addresses ( less linkable ) you could consider updating it with    ( also an individual draft atm ) 
 also suggested that the reference might not be needed in so I made to actually remove it .
Paragraph (version A):
Servers MUST ensure that, if multiple A, AAAA or ALTSVC I-D.schwartz-
httpbis-dns-alt-svc 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 a ESNI TXT record for that
domain.
Paragraph (version B):
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 a ESNI TXT
record for that domain.
Draft: draft-rescorla-tls-esni

Commentary: See 
 This looks good to me . Clarifying the requirements rather than specifying how to act makes more sense here . FWIW , I thought the intent of the original text was to encourage not having ESNIKeys shared between multiple hosts whenever possible . This change loses that property . But anyways , that is mentioned in the appendix . Hence my : +1 : to the PR . 
 I suggest dropping the references to  's individual alt - svc in DNS draft .. it has n't been adopted and its future is murky . actual alt - svc ( the non dns kind ) actually requires the use of the plaintext SNI . As those are both cachable and connections to new IP addresses ( less linkable ) you could consider updating it with    ( also an individual draft atm ) 
 also suggested that the reference might not be needed in so I made to actually remove it . 
 Regarding : Why is that a SHOULD ? Does it apply to both fronting and shared mode ? For reference , Cloudflare almost always sends at least two A and AAAA answers for every question . ( I get that it 's not a MUST , though I 'd also like to understand what the reasoning is in the first place ) 
 ? ? 
 The idea was to simplify key management . If multiple A or AAAA records are returned , the server needs to ensure each server behind those addresses have all the necessary keys . 
 I see , I 'd rather the spec said that instead of trying to impose limits ( I made with suggested fix ) . 
 works for me :)
Paragraph (version A):
Servers SHOULD configure DNS such that, upon querying a domain name
with ESNI support, at most one each of A, AAAA, TXT ESNI, and ALTSVC
I-D.schwartz-httpbis-dns-alt-svc Resource Record is returned.  Alt-
Svc records may be used to inform the client of the plaintext
(fronting) SNI.  If present, clients SHOULD use its value in the SNI
extension of the subsequent ClientHello.
Paragraph (version B):
Servers MUST ensure that, if multiple A, AAAA or ALTSVC I-D.schwartz-
httpbis-dns-alt-svc 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 a ESNI TXT record for that
domain.
Paragraph (version B):
Alt-Svc records may be used to inform the client of the plaintext
(fronting) SNI.  If present, clients SHOULD use its value in the SNI
extension of the subsequent ClientHello.
Draft: draft-rescorla-tls-esni

Commentary: At the moment , there is no extensibility in ESNIKeys . That means that if we want to add additional attributes , we would be forced to define a new DNS record that gets queried simultaneously . I think we do not want to do that . Hence the extensions field . The text is tentative ; please feel free to change in any ways . 
 LGTM . 
 With merged , I wonder if the  struct should just be renamed to something not specific to ESNI , but something more like " generic TLS config in DNS " so that it can be more cleanly reused by unrelated features . " ServerConfiguration " comes to mind from the early TLS 1.3 days . 
 If we were to re - use these keys for other purposes , that seems fine . However , I 'm not sure we want to do that . Semi - static keys , for example , should ideally be separate . 
 The keys yes , but I imagine the extensions field can hold " arbitrary " data , so while the keys would be ESNI - specific , you could also include extensions that have nothing to do with ESNI . 
 Thinking about this some more , this would also require changing the " _ esni . " prefix to something else . In any case I can see how this might be out of scope for this spec . In the end it 's a matter of deciding whether future TLS extensions that need similar DNS records , should be able to reuse the same structure ( so no additional TXT record with its own prefix would be required ) , or if they should define their own structure ( and have a separate TXT record ) . I 'm happy to close this if it goes too much out of scope . 
 Right , I think it 's verging on being out of scope . What do others think ? 
 My preference goes to keeping the name as - is , considering the fact that the role of ESNIKeys is ( at least for the moment ) to negotiate properties between the client and the fronting server ( not the hidden server ) , and that the only property we need to negotiate between the two is the information necessary for ESNI protection . It is true that the DNS record can covey properties related to the hidden server ( as you know , I 've argued for using it to carry the server certificate chain ) . But IMO that 's a change of concept , and I prefer keeping the concept simple for the time being . 
 Ok .
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
I-D.ietf-tls-tls13; 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.
Draft: draft-rescorla-tls-esni

Commentary: A few fixes made while reading through .
Paragraph (version A):
Note: future extensions may end up reusing the server's ESNIKeyShare
for other purposes within the same message (e.g., encrypting other
values).  Those usages MUST have their own HKDF labels to avoid
reuse.
Paragraph (version B):
Note: future extensions may end up reusing the server's
ESNIKeyShareEntry for other purposes within the same message (e.g.,
encrypting other values).  Those usages MUST have their own HKDF
labels to avoid reuse.
Paragraph (version A):
Since the SNI encryption key is derived from a (EC)DH operation
between the client's ephemeral and server's semi-static ESNI key.
This binds the ESNI encryption to the Client Hello.  It is not
possible for an attacker to "cut and paste" the ESNI value in a
different Client Hello, with a different ephemeral key share, as the
terminating server will fail to decrypt and verify the ESNI value.
Paragraph (version B):
Since the SNI encryption key is derived from a (EC)DH operation
between the client's ephemeral and server's semi-static ESNI key, the
ESNI encryption is bound to the Client Hello.  It is not possible for
an attacker to "cut and paste" the ESNI value in a different Client
Hello, with a different ephemeral key share, as the terminating
server will fail to decrypt and verify the ESNI value.
Draft: draft-rescorla-tls-esni

Commentary: LGTM !
Paragraph (version A):
The client MAY either omit the "server_name" extension or provide an
innocuous dummy one (this is required for technical conformance with
RFC7540; Section 9.2.)  Similarly, the client MAY send an innocuous
EncryptedSNI extension if it has no ESNI to send.  If present, this
extension MUST carry a random key label and encryption, as otherwise
it may induce unnecessary work for servers.  This makes it somewhat
harder to determine if ESNI is in use and "greases" I-D.ietf-tls-
grease the use of ESNI on the network.
Draft: draft-rescorla-tls-esni

Commentary: You are mixing in . That would seem to be sufficient . From that you can generate the AEAD nonce and key as though this were record protection . We do n't need another reason for people to complain about exposing the random number generator state to the network . 
 If servers choose to use the same ESNI and semi - static key , not generating and including a nonce could lead to nonce - reuse for 0 - RTT data . We talked about just prohibiting this sort of key sharing for servers , though it 's good to have a client - side defense against it .
Paragraph (version B):
Note: future extensions may end up reusing the server's ESNIKeyShare
for other purposes within the same message (e.g., encrypting other
values).  Those usages MUST have their own HKDF labels to avoid
reuse.