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

Commentary: draft - irtf - cfrg - hpke-05 switched from Unmarshal to Deserialize . Switch ECH to match . See . 
 Cause I 'm quite new to ECH , I 'm little bit confused when reading this draft . So I want to ask some questions ... Paragraph 7.1 . Sending an encrypted ClientHello says ... Q1 . Is ' Unmarshal ( ) ' above equal to general meaning of unmarshalling -get public key from ECHConfig structure- ? Q2 . I think ' hrr ' in the fourth line is the abbreviation of ' HelloRetryRequest ' , is it correct ? If so , could you add some explanation about that ? 
 Q1 : It should be defined in the HPKE draft , though it looks like the HPKE draft has since renamed it and it should probably say Deserialize now . Q2 : hrr is HelloRetryRequest , yes . The use of the key is described later on in the HelloRetryRequest section . 
 The first line appears to be pseudocode for " interpret as a public key for the KEM algorithm identified by . IMO we should get rid of this pseudocode and say what is . beat me to it ! 
 Oh , it was Deserialize ( ) ... thanks ! 
 Closing as resolved .
Paragraph (version A):
Note that the HPKE algorithm identifiers are those which match the
client's chosen preference from "ECHConfig.cipher_suites".
Paragraph (version B):
Note that the HPKE functions Deserialize and SetupBaseS are those
which match "ECHConfig.kem_id" and the client's chosen preference
from "ECHConfig.cipher_suites".
Draft: draft-ietf-tls-esni

Commentary: Addresses 
 The spec uses both and when referring to the contents of . These should be made consistent ( preferably using the former ) . 
 Agreed -- let 's unify around ! Would you be able to propose text ? 
 ( is a remnant of the old name . I guess we missed a few . ) 
 Thanks !
Paragraph (version A):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"ech_required" alert.  It then processes the "retry_keys" field from
the server's "encrypted_client_hello" extension.
Paragraph (version B):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"ech_required" alert.  It then processes the "retry_configs" field
from the server's "encrypted_client_hello" extension.
Paragraph (version A):
If none of the values provided in "retry_keys" contains a supported
version, the client can regard ECH as securely disabled by the
server.  As below, it SHOULD then retry the handshake with a new
transport connection and ECH disabled.
Paragraph (version B):
If none of the values provided in "retry_configs" contains a
supported version, the client can regard ECH as securely disabled by
the server.  As below, it SHOULD then retry the handshake with a new
transport connection and ECH disabled.
Paragraph (version A):
It MUST include the "encrypted_client_hello" extension with the
"retry_keys" field set to one or more ECHConfig structures with
up-to-date keys.  Servers MAY supply multiple ECHConfig values of
different versions.  This allows a server to support multiple
versions at once.
Paragraph (version B):
It MUST include the "encrypted_client_hello" extension with the
"retry_configs" field set to one or more ECHConfig structures with
up-to-date keys.  Servers MAY supply multiple ECHConfig values of
different versions.  This allows a server to support multiple
versions at once.
Draft: draft-ietf-tls-esni

Commentary: This PR fixes a small typo .
Paragraph (version A):
If it supports ECH and can decrypt it, then it forwards the
CllientHelloInner to the backend, who terminates the connection.
This is referred to as "ECH acceptance".
Paragraph (version B):
If it supports ECH and can decrypt it, then it forwards the
ClientHelloInner to the backend, who terminates the connection.
This is referred to as "ECH acceptance".
Draft: draft-ietf-tls-esni

Commentary: This addresses . 
 In Section 6.1 : if I were implementing this extension , I think the simplest thing would be to compress all copied extensions by default : 's not computationally intensive ; minimizes bandwidth overhead ; and 's simpler for future " big " extensions , since no code changes would be needed here . I suggest removing this guidance . 
 addresses this issue .
Paragraph (version A):
Clients SHOULD only use this mechanism for extensions which are
large.  All other extensions SHOULD appear in both ClientHelloInner
and ClientHelloOuter even if they have identical values.
Draft: draft-ietf-tls-esni

Commentary: Consider the following values for L and D , where L is the server 's hint and D is the length of the domain name . This change pads D according to the following rules . D1 : D < = L , so round up to L. D2 : 32(n-1 ) < = L < D < = 32n , round up to 32(n+1 ) . D3 : 32(n-1 ) < = L < = 32n < D , round up to 32(n+1 ) . Case D2 exists because the anonymity set of of D , if rounded to 32n ( instead of 32(n+1 ) , is less than 32 . The new padding algorithm ensures that the anonymity set for D whenever D L is at least 32 elements . Thanks , 
 cc 
 TBH I am not sure that this is worth it , but I believe it is correct . 
 Section 7.2 says This has some problems : L = = D , or D L and D % 32 = = 0 , this results in unnecessary padding . L = = D = = 31 , there is no length protection . The output is 32 , and that is the only length that produces that output . The easiest solution is to replace " 32 - ( D % 32 ) " with " ( L - D ) & 0x1f " . This pads up to the nearest L + 32*n . If it 's considered important to pad to a multiple of 32 , I would suggest ensuring that the initial bucket is at least 32 , e.g.
Paragraph (version A):
If L > D, add L - D bytes of padding.  This rounds to the server's
advertised hint, i.e., ECHConfig.maximum_name_length.
Paragraph (version A):
Otherwise, add 32 - (D % 32) bytes of padding.  This rounds D up
to the nearest multiple of 32 bytes.
Paragraph (version B):
If L >= D, add L - D bytes of padding.  This rounds to the
server's advertised hint, i.e., ECHConfig.maximum_name_length.
Paragraph (version B):
Otherwise, let P = 31 - ((D - 1) % 32), and add P bytes of
padding, plus an additional 32 bytes if D + P < L + 32.  This
rounds D up to the nearest multiple of 32 bytes that permits at
least 32 bytes of length ambiguity.
Draft: draft-ietf-tls-esni

Commentary: This ensures that each paragraph line breaks at 80 characters . No other change is intended ( editorial or otherwise ) . 
 Do you want to borrow the linter that we use in QUIC ? Just copy to your Makefile along with . 
 Brilliant !
Paragraph (version A):
The serialized and encrypted ClientHelloInner structure, AEAD-
encrypted using HPKE with the selected KEM, KDF, and AEAD
algorithm and key generated as described below.
Draft: draft-ietf-tls-esni

Commentary: Fixes a minor search / replace mistake in . 
 Oops . :-)
Paragraph (version A):
A more serious problem is MITM proxies which do not support this
extension.  RFC8446, Section 9.3 requires that such proxies remove
any extensions they do not understand.  The handshake will then
present a certificate based on the public name, without eching the
"encrypted_client_hello" extension to the client.
Paragraph (version B):
A more serious problem is MITM proxies which do not support this
extension.  RFC8446, Section 9.3 requires that such proxies remove
any extensions they do not understand.  The handshake will then
present a certificate based on the public name, without echoing the
"encrypted_client_hello" extension to the client.
Draft: draft-ietf-tls-esni

Commentary: Addresses . 
 Thanks . The changes look to cover my point in . 
 The ID proposes an optional configuration digest parameter to be included in the clientHello . This parameter is advantageous because it improves the efficiency of the solution by avoiding the server having to do trial decryptions . However , in some scenarios the configuration digest could leak privacy information . In version 7 of the ID , section 10.2 on “ Client Tracking ” describes one scenario , but there are others . A more complete and general discussion of the risks and mitigations would be useful . If a particular domain has a unique public key then the configuration digest becomes a fingerprint for that domain . An attacker that has a list of such domains that they want to monitor can build a dictionary of the corresponding digests use this to identify traffic to the domains on their list . Some mitigations could be : 1 ) Avoid the use of configuration digest 2 ) Only deploy in a mode where many domains share the same public key to make finger - printing too general to be useful 3 ) To change keys faster than attackers can update their list of fingerprints 
 This should be addressed by . Please re - open ( and suggest text edits ! ) if you think otherwise .
Paragraph (version A):
Client-facing servers with non-uniform cryptographic configurations
across backend origin servers segment the ECH anonymity set based on
these configurations.  For example, if a client-facing server hosts k
backend origin servers, and exactly one of those backend origin
servers supports a different set of cryptographic algorithms than the
other (k - 1) servers, it may be possible to identify this single
server based on the contents of the ServerHello as this message is
not encrypted.
Paragraph (version B):
Use of ECH does not weaken the security properties of TLS without
ECH.
Paragraph (version B):
Client-facing server configuration determines the size of the
anonymity set.  For example, if a client-facing server uses distinct
ECHConfig values for each host, then each anonymity set has size k =
1.  Client-facing servers SHOULD deploy ECH in such a way so as to
maximize the size of the anonymity set where possible.  This means
client-facing servers should use the same ECHConfig for as many hosts
as possible.  An attacker can distinguish two hosts that have
different ECHConfig values based on the
ClientEncryptedCH.record_digest value.  This also means public
information in a TLS handshake is also consistent across hosts.  For
example, if a client-facing server services many backend origin
hosts, only one of which supports some cipher suite, it may be
possible to identify that host based on the contents of unencrypted
handshake messages.
Draft: draft-ietf-tls-esni

Commentary: See Hopefully this one sticks .
Paragraph (version A):
ECH works by encrypting the entire ClientHello, including the SNI and
any additional extensions such as ALPN.  This requires that each
provider publish a public key and metadata which is used for
ClientHello encryption for all the domains for which it serves
directly or indirectly (via Split Mode).  This document defines the
format of the SNI encryption public key and metadata, referred to as
an ECH configuration, and delegates DNS publication details to
HTTPSSVC, though other delivery mechanisms are possible.  In
particular, if some of the clients of a private server are
applications rather than Web browsers, those applications might have
the public key and metadata preconfigured.
Paragraph (version B):
ECH works by encrypting the entire ClientHello, including the SNI and
any additional extensions such as ALPN.  This requires that each
provider publish a public key and metadata which is used for
ClientHello encryption for all the domains for which it serves
directly or indirectly (via Split Mode).  This document defines the
format of the SNI encryption public key and metadata, referred to as
an ECH configuration, and delegates DNS publication details to HTTPS-
RR, though other delivery mechanisms are possible.  In particular, if
some of the clients of a private server are applications rather than
Web browsers, those applications might have the public key and
metadata preconfigured.
Paragraph (version A):
The cost of this type of attack scales linearly with the desired
number of target clients.  Moreover, DNS caching behavior makes
targeting individual users for extended periods of time, e.g., using
per-client ECHConfig structures delivered via HTTPSSVC RRs with high
TTLs, challenging.  Clients can help mitigate this problem by
flushing any DNS or ECHConfig state upon changing networks.
Paragraph (version B):
The cost of this type of attack scales linearly with the desired
number of target clients.  Moreover, DNS caching behavior makes
targeting individual users for extended periods of time, e.g., using
per-client ECHConfig structures delivered via HTTPS RRs with high
TTLs, challenging.  Clients can help mitigate this problem by
flushing any DNS or ECHConfig state upon changing networks.
Draft: draft-ietf-tls-esni

Commentary: As discussed on the list , add a small bit of text in the section 10.3 to outline the behavior of clients seeking to protect server 's privacy . 
 Thanks !
Paragraph (version A):
Optional record digests may be useful in scenarios where clients and
client-facing servers do not want to reveal information about the
client-facing server in the "encrypted_client_hello" extension.  In
such settings, servers must perform trial decrypt upon receipt of an
empty record digest, which may exacerbate DoS attacks.  Specifically,
an adversary may send malicious ClientHello messages, i.e., those
which will not decrypt with any known ECH key, in order to force
wasteful decryption.  Servers that support this feature should, for
example, implement some form of rate limiting mechanism to limit the
damage caused by such attacks.
Paragraph (version B):
Optional record digests may be useful in scenarios where clients and
client-facing servers do not want to reveal information about the
client-facing server in the "encrypted_client_hello" extension.  In
such settings, clients send either an empty record_digest or a
randomly generated record_digest in the ClientEncryptedCH.  (The
precise implementation choice for this mechanism is out of scope for
this document.)  Servers in these settings must perform trial
decryption since they cannot identify the client's chosen ECH key
using the record_digest value.  As a result, support for optional
record digests may exacerbate DoS attacks.  Specifically, an
adversary may send malicious ClientHello messages, i.e., those which
will not decrypt with any known ECH key, in order to force wasteful
decryption.  Servers that support this feature should, for example,
implement some form of rate limiting mechanism to limit the damage
caused by such attacks.
Draft: draft-ietf-tls-esni

Commentary: We 'll request early codepoints after we get some implementation experience . 
 Yeah , as I was specifying the extension codepoint I noticed the collision between this variable , so I figured changing it here was best . 
 I have no objection to echononce -echononce_value but did you mean to do it in this PR ?
Paragraph (version A):
encrypted_client_hello(57), with "TLS 1.3" column values being set
to "CH, EE", and "Recommended" column being set to "Yes".
Paragraph (version A):
outer_extension(58), with the "TLS 1.3" column values being set to
"CH", and "Recommended" column being set to "Yes".
Paragraph (version B):
encrypted_client_hello(0xff02), with "TLS 1.3" column values being
set to "CH, EE", and "Recommended" column being set to "Yes".
Paragraph (version B):
ech_nonce(0xff03), with the "TLS 1.3" column values being set to
"CH", and "Recommended" column being set to "Yes".
Paragraph (version B):
outer_extension(0xff04), with the "TLS 1.3" column values being
set to "CH", and "Recommended" column being set to "Yes".
Draft: draft-ietf-tls-esni

Commentary: The misrouting content no longer applies since the backend server sees the full CH , with the true SNI .
Paragraph (version A):
Note that the backend server has no way of knowing what the SNI was,
but that does not lead to additional privacy exposure because the
backend server also only has one identity.  This does, however,
change the situation slightly in that the backend server might
previously have checked SNI and now cannot (and an attacker can route
a connection with an encrypted SNI to any backend server and the TLS
connection will still complete).  However, the client is still
responsible for verifying the server's identity in its certificate.
Draft: draft-ietf-tls-esni

Commentary: Once we have some implementations that interop , we 'll go ahead with early codepoint allocation . The new version matches -07 , which will be the next draft version we submit . cc 
 We need to pick some values for the " encryptedclienthello(TBD ) " and for the HTTPSSVC RR type before we can do interop . Allocating some values from the private ranges for those before draft-07 is pushed out would be good so we can do some interop testing . ( Or for whatever is the next draft for which we want to do interop . )
Paragraph (version A):
The version of the structure.  For this specification, that value
SHALL be 0xff03.  Clients MUST ignore any ECHConfig structure with
a version they do not understand.
Paragraph (version B):
The version of the structure.  For this specification, that value
SHALL be 0xff07.  Clients MUST ignore any ECHConfig structure with
a version they do not understand.
Paragraph (version A):
IANA is requested to create an entry, encrypted_client_hello(0xffce),
in the existing registry for ExtensionType (defined in RFC8446), with
"TLS 1.3" column values being set to "CH, EE", and "Recommended"
column being set to "Yes".
Paragraph (version B):
encrypted_client_hello(57), with "TLS 1.3" column values being set
to "CH, EE", and "Recommended" column being set to "Yes".
Paragraph (version B):
outer_extension(58), with the "TLS 1.3" column values being set to
"CH", and "Recommended" column being set to "Yes".
Draft: draft-ietf-tls-esni

Commentary: Seeing no pushback on the list , this moves the draft from Experimental to ST . 
 The design can apply to TLS 1.4 and beyond ( presumably ) . 
 Done in .
Paragraph (version A):
This document defines a mechanism for encrypting a TLS 1.3
ClientHello.
Paragraph (version B):
This document describes a mechanism in Transport Layer Security (TLS)
for encrypting a ClientHello message under a server public key.
Paragraph (version A):
The design in this document introduces a new extension, called
Encrypted Client Hello (ECH), which allows clients to encrypt the
entirety of their ClientHello to a supporting server.  This protects
the SNI and other potentially sensitive fields, such as the ALPN
list.
Paragraph (version B):
The design in this document introduces a new extension, called
Encrypted Client Hello (ECH), which allows clients to encrypt the
entirety of their ClientHello to a supporting server.  This protects
the SNI and other potentially sensitive fields, such as the ALPN
list.  This extension is only supported with (D)TLS 1.3 RFC8446 and
newer versions of the protocol.
Draft: draft-ietf-tls-esni

Commentary: Addresses .
Paragraph (version B):
A malicious client-facing server could distribute unique, per-client
ECHOConfig structures as a way of tracking clients across subsequent
connections.  On-path adversaries which know about these unique keys
could also track clients in this way by observing TLS connection
attempts.
Paragraph (version B):
The cost of this type of attack scales linearly with the desired
number of target clients.  Moreover, DNS caching behavior makes
targeting individual users for extended periods of time, e.g., using
per-client ECHOConfig structures delivered via HTTPSSVC RRs with high
TTLs, challenging.  Clients can help mitigate this problem by
flushing any DNS or ECHOConfig state upon changing networks.
Draft: draft-ietf-tls-esni

Commentary: Addresses . cc 
 And possibly also include a bit inside ESNIConfig that tells clients whether or not to populate record_digest . ( See for some relevant definitions . ) 
 Works for me .
Paragraph (version A):
Supporting optional record digests and trial decryption opens oneself
up to DoS attacks.  Specifically, an adversary may send malicious
ClientHello messages, i.e., those which will not decrypt with any
known ECHO key, in order to force decryption.  Servers that support
this feature should, for example, implement some form of rate
limiting mechanism to limit the damage caused by such attacks.
Paragraph (version B):
Optional record digests may be useful in scenarios where clients and
client-facing servers do not want to reveal information about the
client-facing server in the "encrypted_client_hello" extension.  In
such settings, servers must perform trial decrypt upon receipt of an
empty record digest, which may exacerbate DoS attacks.  Specifically,
an adversary may send malicious ClientHello messages, i.e., those
which will not decrypt with any known ECHO key, in order to force
wasteful decryption.  Servers that support this feature should, for
example, implement some form of rate limiting mechanism to limit the
damage caused by such attacks.
Draft: draft-ietf-tls-esni

Commentary: Addresses . cc 
 There 's no explicit signal indicating that ECHO was negotiated for a connection . Thus , clients must perform trial decryption with both possible handshake keys . If we intend to keep this , then we should crisply state that " do n't stick out " is limited to explicit signals , i.e. , implicit signals such as size - related information is probably out of scope . ( It 's certainly an open question what is the " best " padding scheme for handshake messages . ) cc
Paragraph (version A):
As more clients enable ECHO support, e.g., as normal part of Web
browser functionality, with keys supplied by shared hosting
providers, the presence of ECHO extensions becomes less suspicious
and part of common or predictable client behavior.  In other words,
if all Web browsers start using ECHO, the presence of this value does
not signal suspicious behavior to passive eavesdroppers.
Paragraph (version A):
Additionally, this specification allows for clients to send GREASE
ECHO extensions (see grease-extensions), which helps ensure the
ecosystem handles the values correctly.
Paragraph (version B):
The only explicit signal indicating possible use of ECHO is the
ClientHello "encrypted_client_hello" extension.  Server handshake
messages do not contain any signal indicating use or negotiation of
ECHO.  Clients MAY GREASE the "encrypted_client_hello" extension, as
described in grease-extensions, which helps ensure the ecosystem
handles ECHO correctly.  Moreover, as more clients enable ECHO
support, e.g., as normal part of Web browser functionality, with keys
supplied by shared hosting providers, the presence of ECHO extensions
becomes less unusual and part of typical client behavior.  In other
words, if all Web browsers start using ECHO, the presence of this
value will not signal unusual behavior to passive eavesdroppers.
Draft: draft-ietf-tls-esni

Commentary: Also define the length of the randomly - generated " encrypted_ch " field .
Paragraph (version A):
Select a supported cipher suite, named group, and padded_length
value.  The padded_length value SHOULD be 260 (sum of the maximum
DNS name length and TLS encoding overhead) or a multiple of 16
less than 260.  Set the "suite" field to the selected cipher
suite.  These selections SHOULD vary to exercise all supported
configurations, but MAY be held constant for successive
connections to the same server in the same session.
Paragraph (version A):
Set the "encrypted_client_hello" field to a randomly-generated
string of [TODO] bytes.
Paragraph (version B):
Set the "suite" field to a supported cipher suite.  The selection
SHOULD vary to exercise all supported configurations, but MAY be
held constant for successive connections to the same server in the
same session.
Paragraph (version B):
Set the "encrypted_ch" field to a randomly-generated string of
[TODO] bytes.