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

Commentary: cc/ 
 I do n't think we need to also bump echouterextensions but just in case ... S 
 ECHConfig is defined as The intention was to bump ECHConfig.version from 0xfe0a to 0xfe0b for draft-11 , but this got missed by ( I wrote the PR , so I apologize for my part in missing this . ) How do folks think we should resolve this ? Do we need to cut a new draft with the ambiguity fixed ? 
 Oh whoops , nice catch ! Using definitely wo n't work since the format and corresponding ClientECH extension has changed . I suppose all the implementors could just agree to mentally fix this typo when reading the draft , but may as well cut draft-12 . Draft numbers are cheap . 
 We could try to pick up some editorial changes , too , like those suggested in . 
 I 'd also personally be pretty happy to have in there , but also fine to skip it for what 's supposed to be a small bugfix draft snapshot . 
 +1 I 've not checked recent editorial changes but they 're probably fine too . S 
 I 'd be happy to take in draft-12 as well , though I 'm inclined to think this should strictly be a bugfix / editorial draft . I 'd say let 's wait until   gets off back from PTO and let him make the call . Unless we 're in a hurry , in which case we could ping one of the other authors to merge our changes and cut a draft . 
 Closing as resolved .
Paragraph (version A):
encrypted_client_hello(0xfe0a), with "TLS 1.3" column values set
to "CH, HRR, EE", and "Recommended" column set to "Yes".
Paragraph (version B):
encrypted_client_hello(0xfe0b), with "TLS 1.3" column values set
to "CH, HRR, EE", and "Recommended" column set to "Yes".
Draft: draft-ietf-tls-esni

Commentary: While padding is " described below " , it 's pretty far away now . We also recommend the padding scheme whether or not the value is non - zero . The text about wildcard names also applies in both cases and seems to describe when the server name may exceed the  . This rephases things a bit .
Paragraph (version A):
The longest name of a backend server, if known.  If this value is
not known it can be set to zero, in which case clients SHOULD use
the inner ClientHello padding scheme described below.  That could
happen if wildcard names are in use, or if names can be added or
removed from the anonymity set during the lifetime of a particular
ECH configuration.
Paragraph (version B):
The longest name of a backend server, if known.  If not known,
this value can be set to zero.  It is used to compute padding
(padding) and does not constrain server name lengths.  Names may
exceed this length if, e.g., the server uses wildcard names or
added new names to the anonymity set.
Draft: draft-ietf-tls-esni

Commentary: Apparently this works now !
Paragraph (version A):
The retry mechanism repairs inconsistencies, provided the server is
authoritative for the public name.  If server and advertised keys
mismatch, the server will respond with ech_retry_requested.  If the
server does not understand the "encrypted_client_hello" extension at
all, it will ignore it as required by RFC8446; Section 4.1.2.
Provided the server can present a certificate valid for the public
name, the client can safely retry with updated settings, as described
in handle-server-response.
Paragraph (version B):
The retry mechanism repairs inconsistencies, provided the server is
authoritative for the public name.  If server and advertised keys
mismatch, the server will respond with ech_retry_requested.  If the
server does not understand the "encrypted_client_hello" extension at
all, it will ignore it as required by Section 4.1.2 of RFC8446.
Provided the server can present a certificate valid for the public
name, the client can safely retry with updated settings, as described
in handle-server-response.
Draft: draft-ietf-tls-esni

Commentary: The second ClientHello after HelloRetryRequest reuses the HPKE context and calls Seal / Open a second time . To avoid needing to unnecessarily retain the enc value , and discourage servers from mistakenly recreating the HPKE context , we made it use the empty string but forgot to update the syntax to match .
Paragraph (version A):
The HPKE encapsulated key, used by servers to decrypt the
corresponding "payload" field.
Paragraph (version B):
The HPKE encapsulated key, used by servers to decrypt the
corresponding "payload" field.  This field is empty in
ClientHelloOuters sent in response to HelloRetryRequest.
Draft: draft-ietf-tls-esni

Commentary: One of the motivations for encrypting  in was the leaks from cookie values . If we do n't go with such a construction ( which seems likely ) and instead do or , cookies will be in the clear . That means it is instead on the backend servers to construct cookie values without leaking information . This PR provides security considerations to that effect . Unfortunately the requirements on backend servers within a   deployment are a bit onerous . I suspect , in practice , the answer is that   deployments can not even use cookies on the backend server . Between HRRs being rare and stateless  being unnecessary over TCP or QUIC , that 's hopefully fine . ( Note this is different from , which was about the client - facing server being stateless . This applies if the backend server is stateless . )
Paragraph (version B):
Section 4.2.2 of RFC8446 defines a cookie value that servers may send
in HelloRetryRequest for clients to echo in the second ClientHello.
While ECH encrypts the cookie in the second ClientHelloInner, the
backend server's HelloRetryRequest is unencrypted.This means
differences in cookies between backend servers, such as lengths or
cleartext components, may leak information about the server identity.
Paragraph (version B):
Backend servers in an anonymity set SHOULD NOT reveal information in
the cookie which identifies the server.  This may be done by handling
HelloRetryRequest statefully, thus not sending cookies, or by using
the same cookie construction for all backend servers.
Paragraph (version B):
Note that, if the cookie includes a key name, analogous to Section 4
of RFC5077, this may leak information if different backend servers
issue cookies with different key names at the time of the connection.
In particular, if the deployment operates in Split Mode, the backend
servers may not share cookie encryption keys.  Backend servers may
mitigate this by either handling key rotation with trial decryption,
or coordinating to match key names.
Draft: draft-ietf-tls-esni

Commentary: ClientHello is already a defined structure . No need to wrap it in an opaque byte array . This avoids needing to fill in an extra length prefix in front . 
 Is n't the length prefix there in order to prevent ossification ? 
 Could you elaborate ? I do n't see how this relates to ossification . Note AAD values are n't parsed or even sent over the wire . Rather , the requirement on them is injectivity . 
 If the thinking is one might want to change what goes in the AAD later , the length prefix does n't do anything . You 'd need an actual distinguishing field like a type or version . We get that via labels and such when setting up the ECH context itself . By the time we 've settled on speaking a particular ECH - like protocol , the AAD structure is fixed . 
 Thanks for the clarification . I was confused about the specifics of how this prefix was used . 
 Can probably just say instead of leading with , which is almost always unnecessary .
Paragraph (version A):
The first three parameters are equal to, respectively, the
"ClientECH.cipher_suite", "ClientECH.config_id", and "ClientECH.enc"
fields of the payload of the "encrypted_client_hello" extension.  The
last parameter, "outer_hello", is computed by serializing
ClientHelloOuter with the "encrypted_client_hello" extension set to
the empty string, i.e., the "extension_data" list has zero length.
Note this serialization does not include the four-byte header
included in the Handshake structure.
Paragraph (version B):
The first three parameters are equal to, respectively, the
"ClientECH.cipher_suite", "ClientECH.config_id", and "ClientECH.enc"
fields of the payload of the "encrypted_client_hello" extension.  The
last parameter, "outer_hello", is computed by serializing
ClientHelloOuter with the "encrypted_client_hello" extension set to
the empty string, i.e., the "extension_data" list has zero length.
This serialization uses the ClientHello structure from Section 4.1.2
of RFC8446, which does not include the four-byte header included in
the Handshake structure.
Draft: draft-ietf-tls-esni

Commentary: do n't give both servers a cookie . That is , if a client - facing server forwards the ClientHello , it ca n't do so statelessly without coordinating with the backend . This is a consequence of moving to a single HelloRetryRequest , but it 's a minor one . In most cases , there will be state established anyway just to get the connection forwarded . DTLS might not work that way , but it 's still likely reasonable to assume state . No longer builds on . 
 I guess the dust is still settling on the rest of the HRR mess , but LGTM . 
 +1 -- can we cherry - pick into a separate PR ? 
 I would be happy for you to take that and merge it . 
 Or , I will just rebase -i here . 
 I was thinking about and the discussion on server  checks started by , and I 'm not sure HRR cookies even work in split mode right now . First off , suppose we do n't merge something like . The current text says : This means if you get a cookied  only good for ClientHelloInner , there 's no requirement to stick the cookie in ClientHelloOuter ! But now the client - facing server ca n't see the cookie , so it ca n't be stateless . It would seem like fixes this , but now we have a more fundamental problem : whose cookie ? Suppose the client - facing server wishes to handle HRR statelessly . It decrypts the first ClientHelloInner and forwards it to the backend server . If the backend server responds with HRR , the client - facing server must forward the HRR as - is , or the transcript breaks . But the client - facing server has no opportunity to bind its state ( echhrrkey ) into the HRR cookie . ( Perhaps there is n't even one . If there is , it 's encrypted with the backend server 's key anyway . Either way , it 's fixed now . ) The simplest solution to all this is to only support stateful client - facing servers in split mode , unless the client - facing and backend servers can coordinate enough to share one cookie . I do n't know if that would satisfy everyone . I could imagine doing something horrific to , akin to what we did to , but that sounds really messy . 
 Let 's mark this as an " OPEN ISSUE " in the draft . 
 Done .
Paragraph (version B):
Note that a client-facing server that forwards the first ClientHello
cannot include its own "cookie" extension if the backend server sends
a HelloRetryRequest.  This means that the client-facing server either
needs to maintain state for such a connection or it needs to
coordinate with the backend server to include any information it
requires to process the second ClientHello.
Draft: draft-ietf-tls-esni

Commentary: and also updates the ECH version . I did n't bump the extension codepoint for " echisinner , " since that seems harmless . cc 
 This new version of the draft removes the version - vector dependency , so this should be the last time we update the pinned version . 
 Works for me !
Paragraph (version A):
ECH uses draft-07 of HPKE for public key encryption I-D.irtf-cfrg-
hpke.  The ECH configuration is defined by the following "ECHConfig"
structure.
Paragraph (version B):
ECH uses draft-08 of HPKE for public key encryption I-D.irtf-cfrg-
hpke.  The ECH configuration is defined by the following "ECHConfig"
structure.
Paragraph (version A):
encrypted_client_hello(0xfe09), with "TLS 1.3" column values set
to "CH, EE", and "Recommended" column set to "Yes".
Paragraph (version B):
encrypted_client_hello(0xfe0a), with "TLS 1.3" column values set
to "CH, EE", and "Recommended" column set to "Yes".
Draft: draft-ietf-tls-esni

Commentary: cc 
 LGTM based on the discussion .
Paragraph (version A):
A "HpkeKeyConfig" structure carrying the configuration information
associated with the HPKE public key.  Note that this structure
contains the "config_id" field, which applies to the entire
ECHConfigContents.  Sites MUST NOT publish two
differet"ECHConfigContents" values with the same "HpkeKeyConfig"
value.
Paragraph (version B):
A "HpkeKeyConfig" structure carrying the configuration information
associated with the HPKE public key.  Note that this structure
contains the "config_id" field, which applies to the entire
ECHConfigContents.  Sites MUST NOT publish two different
"ECHConfigContents" values with the same "HpkeKeyConfig" value.
The RECOMMENDED technique for choosing "config_id" is to choose a
random byte.  This process is repeated if this config_id matches
that of any valid ECHConfig, which could include any ECHConfig
that has been recently removed from active use.
Paragraph (version A):
An opaque identifier for the given HPKE key configuration.  This
is used by clients to indicate the key used for ClientHello
encryption.
Paragraph (version B):
A one-byte identifier for the given HPKE key configuration.  This
is used by clients to indicate the key used for ClientHello
encryption.
Paragraph (version A):
If optional configuration identifiers (see optional-configs)) are
used, "config_id" SHOULD be set to a randomly generated eight bytes.
Unless specified by the application using (D)TLS or externally
configured on both sides, implementations MUST compute the field as
specified in encrypted-client-hello.
Paragraph (version B):
If optional configuration identifiers (see optional-configs)) are
used, "config_id" SHOULD be set to a randomly generated byte.  Unless
specified by the application using (D)TLS or externally configured on
both sides, implementations MUST set the field as specified in
encrypted-client-hello.
Paragraph (version A):
"config_id" is replaced with the empty string.
Paragraph (version B):
"config_id" is unchanged and contains the "config_id"
corresponding to the client's chosen ECHConfig.
Paragraph (version A):
Set the "config_id" field to a random eight byte string.
Paragraph (version B):
Set the "config_id" field to a random byte.
Paragraph (version A):
If the client-facing server accepted ECH, it checks the second
ClientHelloOuter also contains the "encrypted_client_hello"
extension.  If not, it MUST abort the handshake with a
"missing_extension" alert.  Otherwise, it checks that
ClientECH.cipher_suite is unchanged, and that ClientECH.config_id and
ClientECH.enc are empty.  If not, it MUST abort the handshake with an
"illegal_parameter" alert.
Paragraph (version B):
If the client-facing server accepted ECH, it checks the second
ClientHelloOuter also contains the "encrypted_client_hello"
extension.  If not, it MUST abort the handshake with a
"missing_extension" alert.  Otherwise, it checks that
ClientECH.cipher_suite and ClientECH.config_id are unchanged, and
that ClientECH.enc is empty.  If not, it MUST abort the handshake
with an "illegal_parameter" alert.
Draft: draft-ietf-tls-esni

Commentary: The reference to " retry keys " comes from when the field was called retrykeys and the type ESNIKeys . We 've since renamed them to retryconfig and ECHConfig , so the prose should match .
Paragraph (version A):
An ECHConfigs structure containing one or more ECHConfig
structures, in decreasing order of preference, to be used by the
client in subsequent connection attempts.
Paragraph (version B):
An ECHConfigs structure containing one or more ECHConfig
structures, in decreasing order of preference, to be used by the
client in subsequent connection attempts.  These are known as the
server's "retry configurations".
Paragraph (version A):
If the server used ClientHelloOuter, the client proceeds with the
handshake, authenticating for ECHConfig.contents.public_name as
described in auth-public-name.  If authentication or the handshake
fails, the client MUST return a failure to the calling application.
It MUST NOT use the retry keys.
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_configs" field
from the server's "encrypted_client_hello" extension.
Paragraph (version B):
If the server used ClientHelloOuter, the client proceeds with the
handshake, authenticating for ECHConfig.contents.public_name as
described in auth-public-name.  If authentication or the handshake
fails, the client MUST return a failure to the calling application.
It MUST NOT use the retry configurations.
Paragraph (version B):
Otherwise, if both authentication and the handshake complete
successfully, 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 at least one of the values contains a version supported by the
client, it can regard the ECH keys as securely replaced by the
server.  It SHOULD retry the handshake with a new transport
connection, using the retry configurations supplied by the server.
The retry configurations may only be applied to the retry connection.
The client MUST continue to use the previously-advertised
configurations for subsequent connections.  This avoids introducing
pinning concerns or a tracking vector, should a malicious server
present client-specific retry keys in order to identify the client in
a subsequent ECH handshake.
Paragraph (version B):
If at least one of the values contains a version supported by the
client, it can regard the ECH keys as securely replaced by the
server.  It SHOULD retry the handshake with a new transport
connection, using the retry configurations supplied by the server.
The retry configurations may only be applied to the retry connection.
The client MUST continue to use the previously-advertised
configurations for subsequent connections.  This avoids introducing
pinning concerns or a tracking vector, should a malicious server
present client-specific retry configurations in order to identify the
client in a subsequent ECH handshake.
Draft: draft-ietf-tls-esni

Commentary: TODO : Ensure that the section numbers referenced in the HPKE draft are still correct .
Paragraph (version A):
ECH uses draft-06 of HPKE for public key encryption I-D.irtf-cfrg-
hpke.  The ECH configuration is defined by the following "ECHConfig"
structure.
Paragraph (version B):
ECH uses draft-07 of HPKE for public key encryption I-D.irtf-cfrg-
hpke.  The ECH configuration is defined by the following "ECHConfig"
structure.
Draft: draft-ietf-tls-esni

Commentary: Clarifies that serialization of this structure does n't include the message type and length . We do the same thing for the serialization of EncodedClientHelloInner , but this makes it explicit in case it 's not clear from context .
Paragraph (version A):
The first three parameters are equal to, respectively, the
"ClientECH.cipher_suite", "ClientECH.config_id", and "ClientECH.enc"
fields of the payload of the "encrypted_client_hello" extension.  The
last parameter, "outer_hello", is computed by serializing
ClientHelloOuter with the "encrypted_client_hello" extension removed.
Paragraph (version B):
The first three parameters are equal to, respectively, the
"ClientECH.cipher_suite", "ClientECH.config_id", and "ClientECH.enc"
fields of the payload of the "encrypted_client_hello" extension.  The
last parameter, "outer_hello", is computed by serializing
ClientHelloOuter with the "encrypted_client_hello" extension removed.
Note this does not include the four-byte header included in the
Handshake structure.
Draft: draft-ietf-tls-esni

Commentary: ~It 's sufficient to ignore it , I think.~ The backend server enforces the extension 's emptiness .
Paragraph (version B):
The "ech_is_inner" is expected to have an empty payload.  If the
payload is non-empty (i.e., the length of the "extension_data" field
is non-zero) then the backend server MUST abort the handshake with an
"illegal_parameter" alert.
Draft: draft-ietf-tls-esni

Commentary: The text for servers rejecting both extensions present is under Backend Server , but the Server Behavior text gates that section under just the one extension . Likewise , the client - facing server text allows for both extensions to be present . Move the illegal_parameter text around and write out the four cases .
Paragraph (version A):
Servers that support ECH play one of two roles, depending on the
extension in the ClientHello.  If the "encrypted_client_hello"
extension is present, the server acts as a client-facing server and
proceeds as described in client-facing-server to extract a
ClientHelloInner, if available.  If the "ech_is_inner" extension is
present and the "encrypted_client_hello" extension is not present,
the server acts as a backend server and proceeds as described in
backend-server.
Paragraph (version B):
If both the "ech_is_inner" and "encrypted_client_hello" extensions
are present in the ClientHello, the backend server MUST abort with
an "illegal_parameter" alert.
Paragraph (version B):
If only the "encrypted_client_hello" extension is present, the
server acts as a client-facing server and proceeds as described in
client-facing-server to extract a ClientHelloInner, if available.
Paragraph (version B):
If only the "ech_is_inner" extension is present and the
"encrypted_client_hello" extension is not present, the server acts
as a backend server and proceeds as described in backend-server.
Paragraph (version B):
If neither extension is present, the server completes the
handshake normally, as described in RFC8446.
Paragraph (version A):
Upon receipt of an "ech_is_inner" extension in a ClientHello, if the
backend server negotiates TLS 1.3 or higher, then it MUST confirm ECH
acceptance to the client by computing its ServerHello as described
here.  If both the "ech_is_inner" and "encrypted_client_hello"
extensions are present in the ClientHello, the backend server MUST
abort with an "illegal_parameter" alert.
Paragraph (version B):
Upon receipt of an "ech_is_inner" extension in a ClientHello, if the
backend server negotiates TLS 1.3 or higher, then it MUST confirm ECH
acceptance to the client by computing its ServerHello as described
here.
Draft: draft-ietf-tls-esni

Commentary: ESNI seems to rely on TLS 1.3 KeyShareEntry which makes it incompatible with TLS 1.2 . That 's unfortunate with that " The protocol designed in this document is quite straightforward . " The gist of ESNI comes down to " encryptedservername extension , which contains the true extension encrypted under the provider ’s public key . " That seems pretty generic and backwards compatible . 
 To prevent cut - and - paste attacks , you need to bind ESNI to the CH . That means we ’d need 1.2 clients to send a key share in the CH to use when deriving encryption keying material , and that ’s not currently done . 
 Since TLS 1.2 sends the server certificate in plaintext it seems like ESNI would n't be particularly useful there anyway , no ? 
 Indeed . I guess someone could argue about wildcard certificates or when multiple names are present but the names are usually related so I agree there ’s no significant benefit from encrypting the SNI .
Paragraph (version A):
ECH uses draft-05 of HPKE for public key encryption I-D.irtf-cfrg-
hpke.  The ECH configuration is defined by the following "ECHConfig"
structure.
Paragraph (version B):
ECH uses draft-06 of HPKE for public key encryption I-D.irtf-cfrg-
hpke.  The ECH configuration is defined by the following "ECHConfig"
structure.