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

Commentary: Followup on . Looks like ESNIConfig is the only ESNI structure that has extensions , now that we 've delegated the key delivery to HTTPSSVC . Should I avoid reflowing the text ? 
 states : same type in a given extension block . The ESNI draft should probably explicitly restate this for both and . I 'd be happy to make a PR if need be . Thanks ! 
 if you could propose text that takes the new ESNIConfig and HTTPSSVC change into account , that 'd be great ! 
 Fixed by .
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.  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 ESNIConfig content.
Paragraph (version B):
A list of extensions that the client can take into consideration
when generating a Client Hello message.  The purpose of the field
is to provide room for additional features in the future.  The
format is defined in RFC8446; Section 4.2.  The same
interpretation rules apply: extensions MAY appear in any order,
but there MUST NOT be more than one extension of the same type in
the extensions block.  An extension may be tagged as mandatory by
using an extension type codepoint with the high order bit set to
understand must reject the ESNIConfig content.
Draft: draft-ietf-tls-esni

Commentary: Add missing description for ciphersuites and add colon symbol to paddedlength
Paragraph (version B):
The list of cipher suites which can be used by the client to
encrypt the SNI.
Draft: draft-ietf-tls-esni

Commentary: Credits to
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.  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 ESNIRecord values in
response to a ESNI record query, each containing an ESNIKeys value.)
The client MUST NOT send encrypted SNI using groups or cipher suites
not advertised by the server.
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_server_name" extension and used to derive the SNI
encryption key.  It does not affect the (EC)DHE shared secret used in
the TLS key schedule.  The client 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
ESNIRecord values in response to a ESNI record query, each containing
an ESNIKeys value.)  The client MUST NOT send encrypted SNI using
groups or cipher suites not advertised by the server.
Paragraph (version A):
The client MUST place the value of ESNIKeys.public_name in the
"server_name" extension.  (This is required for technical conformance
with RFC7540; Section 9.2.)  The client MUST NOT send a "cached_info"
extension RFC7924 with a CachedObject entry whose
CachedInformationType is "cert".
Paragraph (version B):
The client MUST place the value of ESNIKeys.public_name in the
"server_name" extension.  (This is required for technical conformance
with RFC7540; Section 9.2.)  The client MUST NOT send a "cached_info"
extension RFC7924 with a CachedObject entry whose
CachedInformationType is "cert", since this indication would divulge
the true server name.
Draft: draft-ietf-tls-esni

Commentary: I got a little tripped up on this point ! Maybe you have a better way to explain it . 
 Thanks ,
Paragraph (version B):
Note that ESNIContents will not be directly transmitted to the server
in the ClientHello.  The server will instead reconstruct the same
object by obtaining its values from ClientEncryptedSNI and
ClientHello.
Paragraph (version B):
Same value as ClientEncryptedSNI.record_digest.
Paragraph (version B):
Same value as ClientEncryptedSNI.key_share.
Paragraph (version B):
Same nonce as ClientHello.random.
Draft: draft-ietf-tls-esni

Commentary: Thank you !
Paragraph (version A):
The KeyShareEntry carrying the client's public ephemeral key
shared used to derive the ESNI key.
Paragraph (version B):
The KeyShareEntry carrying the client's public ephemeral key share
used to derive the ESNI key.
Draft: draft-ietf-tls-esni

Commentary: Since OCSP is the server name , ESNI should probably enforce OCSP stapling ( similar to ) or any other way of encrypted OCSP checks . Ignoring OCSP status checks entirely makes it hard to revoke a certificate , even if it 's only valid for a few months . 
 what behavior do you expect here ? Would clients fail hard if server do n't send stapled responses ? It 's good to view ESNI as part of the leaky boat problem . It plugs one hole , but not all of them . Implementations probably should do something about cleartext OCSP if they want all holes plugged . 
 Thank you for the changes . LGTM .
Paragraph (version B):
ESNI requires encrypted DNS to be an effective privacy protection
mechanism.  However, verifying the server's identity from the
Certificate message, particularly when using the X509
CertificateType, may result in additional network traffic that may
reveal the server identity.  Examples of this traffic may include
requests for revocation information, such as OCSP or CRL traffic, or
requests for repository information, such as
authorityInformationAccess.  It may also include implementation-
specific traffic for additional information sources as part of
verification.
Paragraph (version B):
Implementations SHOULD avoid leaking information that may identify
the server.  Even when sent over an encrypted transport, such
requests may result in indirect exposure of the server's identity,
such as indicating a specific CA or service being used.  To mitigate
this risk, servers SHOULD deliver such information in-band when
possible, such as through the use of OCSP stapling, and clients
SHOULD take steps to minimize or protect such requests during
certificate validation.
Draft: draft-ietf-tls-esni

Commentary: [ 1 ] 
 Extensibility failed for SNI , no point in repeating that failure . This is less complex : 
 Are there other ways we expect servers to select certificates ? I can imagine a scenario where clients pin server leaf certificates , and hint servers to the right leaf certificate by sending the leaf SPKI hash in the SNI . Would we want to rule something like that out ?
Mailing list commentary: The Server Name Indication ( SNI ) extension in TLS has a provision to provide names other than host names[1 ] . None have even been defined to my knowledge , but it 's there . OpenSSL ( and possibly others ) have had a long - standing bug[2 ] ( fixed in master ) that means that different types of names will cause an error . To be clear : I live in a glass house and am not throwing stones ; these things happen . However , it means that a huge fraction of the TLS deployment will not be able to accept a different name type should one ever be defined . ( This issue might have been caused by the fact that the original[3 ] spec did n't define the extension in such a way that unknown name types could be skipped over . ) Therefore we ( i.e. BoringSSL , and thus Google ) are proposing to give up on this and implement our parser such that the SNI extension is only allowed to contain a single host name value . ( This is compatible with all known clients . ) We 're assuming that since this is already the de - facto reality that there will be little objection . I ' m sending this mostly to record the fact so that , if someone tries to define a new name type in the future , they wo n't waste their time . If the community wishes to indicate a different type of name in the future , a new extension can be defined . This is already effectively the case because we would n't fight this level of incompatibility when there 's any other option . ( I think the lesson here is that protocols should have a single joint , and that it should be kept well oiled . For TLS , that means that extensions should have minimal extensionality in themselves and that we should generally rely on the main extensions mechanism for these sorts of things . ) [ 1 ] [ 2 ] – note that the data pointer is not updated . [ 3 ] Cheers AGL
Paragraph (version A):
The true SNI, that is, the ServerNameList that would have been
sent in the plaintext "server_name" extension.
Paragraph (version B):
The true SNI DNS name, that is, the HostName value that would have
been sent in the plaintext "server_name" extension.  (NameType
values other than "host_name" are unsupported since SNI
extensibility failed SNIExtensibilityFailed).
Draft: draft-ietf-tls-esni

Commentary: I believe it will be helpful to understanding this document to either add " Presentation Language " to this document or link to Presentation Language elsewhere . The TLS/1.3 document has something similar in
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.  All TLS notation comes from RFC8446; Section 3.
Draft: draft-ietf-tls-esni

Commentary: The checksum seems to add little value with the retry mechanism and record_digest . I think we should remove it . See for some context . 
 The I - D says : " recorddigest : A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained , i.e. , from the first byte of " checksum " to the end of the structure . This hash is computed using the hash function associated with suite . " From looking at the NSS code it appears that the recorddigest input is actually the entire ESNIKeys ( after base64 decode ) including the version and checksum . Is that correct ? IOW , does the following also produce the right value ( for CF and sha256 ) ? ` 
 proposes removing the checksum , which should clear this up . 
 Closing since landed . please re - open if this is still an issue ! 
 The hash used in the extension should use the same hash inputs as the checksum . The difference here just makes using this harder . 
 I support the change , if that makes people feel more comfortable about having the checksum field in ESNIKeys . 
 I 'm not opposed , but it does n't help as much as you might think , because you need to compute the label with the cipher hash and not ( necessarily ) with SHA-256 . 
 So , if you take my suggestion in ( which I know does n't like , but we simply disagree about that ) , then you can identify the ESNI using a truncated hash that is calculated using the cipher hash because it only appears in the context of a handshake . But that just suggests that this is either not - helpful because we chose not to do anything in , or it is not necessary because we did . I 'm OK closing this on that basis . 
 Checksum is now gone . Closing this issue . thanks for filing it ! 
 I agree that we can now and should make this simplification . The PR looks good to me .
Paragraph (version A):
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.
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.
Paragraph (version B):
In the event that ESNIKeys is corrupt in transit or otherwise
invalid, servers will initiate the retry mechanism described in
server-behavior and deliver valid ESNIKeys to clients.
Paragraph (version A):
A cryptographic hash of the ESNIKeys structure from which the ESNI
key was obtained, i.e., from the first byte of "checksum" to the
end of the structure.  This hash is computed using the hash
function associated with "suite".
Paragraph (version B):
A cryptographic hash of the ESNIKeys structure from which the ESNI
key was obtained, i.e., from the first byte of "version" to the
end of the structure.  This hash is computed using the hash
function associated with "suite".
Draft: draft-ietf-tls-esni

Commentary: We now have a proper retry mechanism , so we do n't need to prevent clients to connect using expired keys anymore . 
 notes that the notbefore and notafter fields are there and described , but not really part of the operational notes . Having something there that talks about these , particularly as it relates to clock skew , would be valuable . 
 ( My ~monthly login into - this 'd be better on the TLS WG list , and I will send mail on this sometime but anyway ... ) The not - before and not - after fields are a mistake . Same as turned out true for x.509 . I was just doing testing where FF nightly barfed on ESNIKeys I 'd published for only that non - reason . ( There is no overall security win in so - doing , in general . ) Creating a tangle between the cadence at which one updates DNS , the ESNIKeys - internal " lifetime " of a key , the DNS TTL and server - state is basically just pointless nonsense . Let 's delete those fields from ESNIKeys before we 're done and just rely on DNS for what it already does . 
 Now that has been merged , I agree that there is less need for notbefore and notafter fields . Previously , a client using an expired key led to connection failure , and therefore having these fields were necessary . 
 Fixed by removing these fields with . 
 Thank you for the PR . LGTM
Paragraph (version A):
The moment when the keys become valid for use.  The value is
represented as seconds from 00:00:00 UTC on Jan 1 1970, not
including leap seconds.
Paragraph (version A):
The moment when the keys become invalid.  Uses the same unit as
not_before.
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.  If
none of the ESNI keys values are acceptable, the client SHOULD behave
as if no ESNI records were found.
Paragraph (version A):
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):
Client MAY cache the ESNIRecord values for a particular domain based
on the TTL of the Resource Record, but SHOULD NOT cache them based on
the not_after value of the ESNIKeys structure, to allow servers to
rotate the keys often and improve forward secrecy.
Draft: draft-ietf-tls-esni

Commentary: The current text about anonymity sets for records is too restrictive . If I have names and 100 IPs and for all queries I randomly return four out of my 100 IPs chosen randomly , I still provide the same anonymity set but I violate the SHOULD . The proposed text 
 The document currently states : I think this is too restrictive . If I have names and 100 IPs and for all queries I randomly return four out of my 100 IPs chosen randomly , I still provide the same anonymity set but I violate the SHOULD . How about : 
 Agreed . At a minimum this should reference a set of A and AAAA records rather than " the record " ( as many records across the A and AAAA rrsets is very common ) . I think proposed text is fine . 
 sgtm , do you plan to open a PR ? I made but I think your wording is better . 
 Created 
 LGTM -- thanks !
Paragraph (version A):
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):
Content providers operating in Split Mode SHOULD ensure that the A
and AAAA records for ESNI-enabled server names do not allow
identifying the server name from the IP address.  This can for
example be achieved by always returning the same records for all
ESNI-enabled names, or by having the function that picks addresses
from a pool not depend on the server name.  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-ietf-tls-esni

Commentary: The draft currently states : I 'm confused about what this means . From reading RFC 7838 , I 'm not sure the SNI and DNS names do not match when you 're querying an alternate name . In particular , RFC 7838 states : Which means , if I understand it correctly , the client will send " " in the SNI when trying to query resources from it - the requirement is only that the certificate for " " also cover " " . 
 Agreed . I 'm parsing RFC 7838 the same way . I think we should drop this text . 
 The problem the text presents is real ( though the resolution is arbitrary ) . no .. that 's a misread . See section 2.3 of 7838 The alternate is essentially just a cname for the origin . If host b is an alternate for origin a , in order to use the alternate you look up the DNS a / aaaa of b , do a TCP connect to b , and then use sni = a and expect a certificate valid for a. ( indeed the point of the SNI is to tell the server what certificate you expect to see ) With esni you would continue to do all of those things , except of course sni = encrypted(a ) .. and the question becomes where do you find the key used for the encryption . Is it the ESNI DNS record of a ( the origin ) or b ( the alternate host ) . That 's the question the text is trying to resolve - it says to use a ( the origin ) . I could make a case for either choice but I think the text needs to decide 
 Would you mind suggesting some text with an example to clear this up ? 
 thanks for the clarification and pointer to s2.3 of 7838 . After reading that I think the text in the ESNI draft looks fine . ( I 'd just add a pointer to s2.3 of 7838 instead of just 7838 to help prevent the confusion I had )
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 is being used,
the SNI domain should be used for querying the ESNI record.
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 Section 2.3 is
being used, the SNI domain should be used for querying the ESNI
record.
Draft: draft-ietf-tls-esni

Commentary: please have a look . 
 We also need to specify server - side HRR behavior , right ? Specifically , the server MUST recheck the second ClientHello 's ESNI extension before sending the server certificate , otherwise putting the key share into the AD field does n't really mean anything . The attacker would be able to do a cut - and - paste thing . ( We could also incorporate the nonce into key schedule , but that upsets the document 's split mode use case . ) 
 Yep ! Thanks for bringing that up . I 'll prepare text . 
 Thank you for the text . LGTM .
Paragraph (version B):
If the server sends a HelloRetryRequest in response to the
ClientHello and the client can send a second updated ClientHello per
the rules in RFC8446, the "encrypted_server_name" extension values
which do not depend on the (possibly updated)
ClientHello.KeyShareClientHello, i.e,, ClientEncryptedSNI.suite,
ClientEncryptedSNI.key_share, and ClientEncryptedSNI.record_digest,
MUST NOT change across ClientHello messages.  Moreover,
ClientESNIInner.nonce and ClientESNIInner.realSNI MUST not change
across ClientHello messages.  Informally, the values of all
unencrypted extension information, as well as the inner extension
plaintext, must be consistent between the first and second
ClientHello messages.
Draft: draft-ietf-tls-esni

Commentary: Addresses . 
 An adversary who observes the certificate fingerprint could confirm certificates previously fetched by a ESNI - compatible client . 
 Fixed in .
Paragraph (version B):
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.).  The client MUST NOT send a "cached_info"
extension RFC7924 with a CachedObject entry whose
CachedInformationType is "cert".
Draft: draft-ietf-tls-esni

Commentary: There were two minor typos . This PR fixes them . While I was at it , I ran over it , most seemed fine .
Paragraph (version A):
This design is not forward secret because the server's ESNI key is
static.  However, the window of exposure is bound by the key
lifetime.  It is RECOMMEMDED that servers rotate keys frequently.
Paragraph (version B):
This design is not forward secret because the server's ESNI key is
static.  However, the window of exposure is bound by the key
lifetime.  It is RECOMMENDED that servers rotate keys frequently.