jiebi/TextFlow huggingface dataset:
Original text:
is not present or does not validate, the server MUST abort the handshake.  Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder <del> that corresponds to that PSK.  See [client-hello-recording] for the security rationale for this requirement.  In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. </del>  Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite

Reviewer comments:
As naïve handling of external identities may cause the server to be vulnerable to identity enumeration attacks, refer the section that discusses that danger in the PSK section itself.

Revised text:
is not present or does not validate, the server MUST abort the handshake.  Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder  <ins> that corresponds to that PSK.  See [client-hello-recording] and [psk- identity-exposure] for the security rationale for this requirement. In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. </ins> Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite
Original text:
This alert notifies the recipient that the sender will not send any more messages on this connection.  Any data received after a <del> closure alert has been received MUST be ignored. </del>  This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a

Reviewer comments:
closenotify has always used a warning alert level, but this is not actually written down anywhere. It seems to have gotten lost as early as RFC 4346 (TLS 1.1!). In RFC 2246, there is some text that mentions the correct level is warning as an aside in describing something else. I wasn't able to find any other text that discussed this. Then, RFC 4346 dropped the session termination behavior: But in doing so, it dropped any mention of which alert level to use. That text has carried over to RFC 8446 as: In RFC 8446, we said alert levels no longer matter and can be "safely ignored", but this still leaves unspecified what the sender should do. Skimming implementations, both BoringSSL and NSS will treat "fatal" closenotify as an error, so using "warning" is also necessary for interop.

Revised text:
This alert notifies the recipient that the sender will not send any more messages on this connection.  Any data received after a  <ins> closure alert has been received MUST be ignored.  This alert MUST be sent with AlertLevel=warning. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a
Original text:
not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors <del> of protocols that run on top of TLS. </del>  This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a

Reviewer comments:
The last few years I have personally experienced several occasions where people in SDOs as well as developers believe that TLS magically gives them authentication. This has resulted in security standards that just writes that "TLS is used for mutual authentication" without any more details as well as implementations that do not provide any identity verification at all and instead just doing a full path validation, when they should have checked the server identity, that the right trust anchor was used, and that the right intermediate CA was used. I think this is a common problem. Reading RFC8446, I think it is quite easy for people without expertise in security protocols to get the understanding that TLS gives you authentication. Suggestions: I think RFC8446 should be clearer with that what is provided by the TLS protocol is transport of authentication credentials and proof-of-possession of the private authentication key. I think the requirements on the application using TLS should be clearer. Maybe: "Application protocols using TLS MUST specify how to initiate TLS handshaking, how to do path validation, and how to do identity verification." I think it would be very good for readers if draft-ietf-uta-rfc6125bis was given as an informative reference.

Revised text:
not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors  <ins> of protocols that run on top of TLS.  Application protocols using TLS MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS with applicaiton protocols. </ins> This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a
Original text:
Freeze & deprecate record layer version field.  draft-05 Prohibit SSL negotiation for backwards compatibility.

Reviewer comments:
Merging PR 100 added to the changelog at draft-04, but we're up to draft-06 now.

Revised text:
Freeze & deprecate record layer version field. <ins> Update format of signatures with context. </ins> draft-05 Prohibit SSL negotiation for backwards compatibility.
Original text:
1.2. <del> draft-07 - Integration of semi-ephemeral DH proposal. </del>  Add initial 0-RTT support

Reviewer comments:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Revised text:
1.2.  <ins> draft-08 Remove support for weak and lesser used named curves. Remove support for MD5 and SHA-224 hashes with signatures. draft-07 Integration of semi-ephemeral DH proposal. </ins> Add initial 0-RTT support
Original text:
digital signatures.  The "extension_data" field of this extension contains a "supported_signature_algorithms" value. <del> %%% Signature Algorithm Extension enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </del>  Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated

Reviewer comments:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Revised text:
digital signatures.  The "extension_data" field of this extension contains a "supported_signature_algorithms" value.  <ins> %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </ins> Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated
Original text:
SHA-224, SHA-256, SHA-384, and SHA-512 SHS, respectively.  The "none" value is provided for future extensibility, in case of a signature algorithm which does not require hashing before signing.  This field indicates the signature algorithm that may be used.

Reviewer comments:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Revised text:
SHA-224, SHA-256, SHA-384, and SHA-512 SHS, respectively.  The "none" value is provided for future extensibility, in case of a signature algorithm which does not require hashing before signing. <ins> The usage of MD5 and SHA-224 are deprecated.  The md5_RESERVED and sha224_RESERVED values MUST NOT be offered or negotiated by any implementation. </ins> This field indicates the signature algorithm that may be used.
Original text:
appropriate rules. If the client supports only the default hash and signature algorithms <del> (listed in this section), it MAY omit the signature_algorithms </del>  extension.  If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key share), it MUST send the <del> signature_algorithms extension, listing the algorithms it is willing to accept. </del>  <del> If the client does not send the signature_algorithms extension, the </del>  server MUST do the following: If the negotiated key exchange algorithm is one of (DHE_RSA,

Reviewer comments:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Revised text:
appropriate rules. If the client supports only the default hash and signature algorithms  <ins> (listed in this section), it MAY omit the "signature_algorithms" </ins> extension.  If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key share), it MUST send the  <ins> "signature_algorithms" extension, listing the algorithms it is willing to accept. </ins>  <ins> If the client does not send the "signature_algorithms" extension, the </ins> server MUST do the following: If the negotiated key exchange algorithm is one of (DHE_RSA,
Original text:
1.2. <del> draft-09 The maximum permittion record expansion for AEAD has been reduced from 2048 to 256 octets. </del> draft-08 Remove support for weak and lesser used named curves.

Reviewer comments:
NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)

Revised text:
1.2.  draft-08 Remove support for weak and lesser used named curves.
Original text:
Revise list of currently available AEAD cipher suites.  draft-07 Integration of semi-ephemeral DH proposal.

Reviewer comments:
NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)

Revised text:
Revise list of currently available AEAD cipher suites. <ins> Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. </ins> draft-07 Integration of semi-ephemeral DH proposal.
Original text:
generated. An AEAD cipher MUST NOT produce an expansion of greater than 256 <del> bytes.  An endpoint that receives a record that is larger than 2^14+256 octets MUST generate a fatal "record_overflow" alert. </del>  As a special case, we define the NULL_NULL AEAD cipher which is simply the identity operation and thus provides no security.  This

Reviewer comments:
NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)

Revised text:
generated. An AEAD cipher MUST NOT produce an expansion of greater than 256  <ins> bytes.  An endpoint that receives a record that is larger than 2^14 + 256 octets MUST generate a fatal "record_overflow" alert. </ins> As a special case, we define the NULL_NULL AEAD cipher which is simply the identity operation and thus provides no security.  This
Original text:
A TLSCiphertext record was received that had a length more than <del> 2^14+256 bytes, or a record decrypted to a TLSPlaintext record </del>  with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).

Reviewer comments:
NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)

Revised text:
A TLSCiphertext record was received that had a length more than  <ins> 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record </ins> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
Original text:
When this message will be sent: <del> If this message is sent, it MUST be sent immediately after the </del>  ServerHello message.  This is the first message that is encrypted under keys derived from ES.

Reviewer comments:
I think that the decision was to make this mandatory, since present-but-empty is harder to screw up.
Section 6.2 Figure 1 and others show messages as non-optional. Section 6.3.3 however states that: It seems that the message could indeed be omitted if the server doesn't need to respond with any extensions, but I may be wrong here. We should fix one of the two places though as they contradict each other.

Revised text:
When this message will be sent:  <ins> The EncryptedExtensions message MUST be sent immediately after the </ins> ServerHello message.  This is the first message that is encrypted under keys derived from ES.
Original text:
below). The client specifies the cryptographic configuration for the 0-RTT <del> data using the "configuration", "cipher_suite", and "extensions" </del>  values.  For configurations received in-band (in a previous TLS connection) the client MUST:

Reviewer comments:
The text & struct have different names for the config ID. Use the one in the struct.

Revised text:
below). The client specifies the cryptographic configuration for the 0-RTT  <ins> data using the "configuration_id", "cipher_suite", and "extensions" </ins> values.  For configurations received in-band (in a previous TLS connection) the client MUST:
Original text:
of the following octets.  Note that the first two octets indicate the extension type ("supported_groups" extension):  [[TODO: IANA Considerations.]] 6.3.2.3.

Reviewer comments:
You'll also need to update the last paragraph of the MTI Extensions section (currently section 8.2). Now that we're going to be down to only one client-only extension defined in this document, that whole paragraph can probably be cut in favor of a one-off note in the remaining extension's section (signature_algorithms will be the last).
So that the clients can learn about what groups a server supports. The idea here is to allow a client to offer P256 but then learn that a server supports 25519 for next time without the server having to reject.

Revised text:
of the following octets.  Note that the first two octets indicate the extension type ("supported_groups" extension): <ins> As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client.  If the server has a group it prefers to the ones in the "key_share" extension but is still willing to accept the ClientHello, it SHOULD send "supported_groups" to update the client's view of its preferences.  Clients MUST NOT act upon any information found in "supported_groups" prior to successful completion of the handshake, but MAY use the information learned from a successfully completed handshake to change what groups they offer to a server in subsequent connections. </ins> [[TODO: IANA Considerations.]] 6.3.2.3.
Original text:
lacking a "server_name" extension with a fatal "missing_extension" alert. <del> Some of these extensions exist only for the client to provide additional data to the server in a backwards-compatible way and thus have no meaning when sent from a server.  The client-only extensions defined in this document are: "signature_algorithms" & "supported_groups".  Servers MUST NOT send these extensions.  Clients receiving any of these extensions MUST respond with a fatal </del>  "unsupported_extension" alert and close the connection. 9.

Reviewer comments:
You'll also need to update the last paragraph of the MTI Extensions section (currently section 8.2). Now that we're going to be down to only one client-only extension defined in this document, that whole paragraph can probably be cut in favor of a one-off note in the remaining extension's section (signature_algorithms will be the last).
So that the clients can learn about what groups a server supports. The idea here is to allow a client to offer P256 but then learn that a server supports 25519 for next time without the server having to reject.

Revised text:
lacking a "server_name" extension with a fatal "missing_extension" alert.  <ins> Servers MUST NOT send the "signature_algorithms" extension; if a client receives this extension it MUST respond with a fatal </ins> "unsupported_extension" alert and close the connection. 9.
Original text:
The TLS handshake establishes one or more input secrets which are combined to create the actual working keying material, as detailed <del> below.  The key derivation process makes use of the following functions, based on HKDF RFC5869: </del>  Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, <del> InputSecret_2, etc.  The initial secret is simply a string of 0s as long as the size of the Hash that is the basis for the HKDF. </del>  Concretely, for the present version of TLS 1.3, secrets are added in the following order:

Reviewer comments:
Some small tweaks and fixes for issue : Move HKDF-Extract citing to a sentence and bring HKDF-Extract with it. Change the Messages arg to HashValue, as the actual hashing is stated in the definition of Derive-Secret which is passing this function a hash, not messages. (fixes issue ) More concise defining of HkdfLabel. Use the word "zeroes" instead of "0s". Edited to add: Also, appended a commit to fix an extra trailing paren.
The other possibility is that a hash of the concatenation of hashes was to be the new HashValue. Simplest change is just to make the arg for what's currently used in the definition and passed in.
NAME Rebased. Is this ok to merge now?
It never actually says that hash_value is H(messages).
This should be clear now.

Revised text:
The TLS handshake establishes one or more input secrets which are combined to create the actual working keying material, as detailed  <ins> below.  The key derivation process makes use of the HKDF-Extract and HKDF-Expand functions as defined for HKDF RFC5869, as well as the functions defined below: </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1,  <ins> InputSecret_2, etc.  The initial secret is simply a string of zeroes as long as the size of the Hash that is the basis for the HKDF. </ins> Concretely, for the present version of TLS 1.3, secrets are added in the following order:
Original text:
The "extension_data" field of this extension contains a "NamedGroupList" value: <del> %%% Named Group Extension </del>  Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4

Reviewer comments:
We have a registry called "supported groups", and the extension is "supported groups"; but each element is called a "named group" and the data passed in the extension is a "named group list". be consistent in our terminology.

Revised text:
The "extension_data" field of this extension contains a "NamedGroupList" value:  <ins> %%% Supported Groups Extension </ins> Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4