jiebi/TextFlow huggingface dataset:
Original text:
%%% Key Exchange Messages <del> X and Y respectively are the binary representations of the X and Y </del>  values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters.  For P-256 this means that each of X and Y use take 48 octets each, and for P-521 they take 66 octets each. For the curves secp256r1, secp384r1 and secp521r1, peers MUST <del> validate each other's public value Y by ensuring that the point is a </del>  valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three <del> steps: (1) verify that the point (X, Y) is not the point at infinity (O), (2) verify that both X and Y are integers in the correct interval, (3) ensure that (X, Y) is a correct solution to the elliptic curve equation.  For these curves, implementors do not need </del>  to verify membership in the correct subgroup. For X25519 and X448, the contents of the public value are the byte

Reviewer comments:
I might do "both integers x and y" but I can see how it would be okay as-is.

Revised text:
%%% Key Exchange Messages  <ins> X and Y respectively are the binary representations of the x and y </ins> values in network byte order.  There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters.  For P-256 this means that each of X and Y use take 48 octets each, and for P-521 they take 66 octets each. For the curves secp256r1, secp384r1 and secp521r1, peers MUST  <ins> validate each other's public value Q by ensuring that the point is a </ins> valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three  <ins> steps: (1) verify that Q is not the point at infinity (O), (2) verify that for Q = (x, y) both integers x and y are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need </ins> to verify membership in the correct subgroup. For X25519 and X448, the contents of the public value are the byte
Original text:
9.3. This section describes invariants that TLS endpoints and middleboxes <del> MUST follow.  It also applies to earlier versions, which assumed these rules but did not document them. </del>  TLS is designed to be securely and compatibly extensible.  Newer clients or servers, when communicating with newer peers, should

Reviewer comments:
ClientHello, etc., processing rules are in earlier versions too. We're just calling out some corollaries of it all.

Revised text:
9.3. This section describes invariants that TLS endpoints and middleboxes  <ins> MUST follow.  It also applies to earlier versions of TLS. </ins> TLS is designed to be securely and compatibly extensible.  Newer clients or servers, when communicating with newer peers, should
Original text:
OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an <del> "unsupported_certificate" alert. </del>  PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching

Reviewer comments:
We should say something about whether the same OID is allowed to appear multiple times in the oid_filters extension (and if it is, what the semantics are). Extracted from
As noted in my comments, there is a natural semantic for multiple, but it seems a bit silly. I think it would be fine to forbid them, though.
I think it's OK to limit to one appearance of a given OID in the oid_filters. (It probably does not matter much in terms of code complexity either way.)
I'm inclined to limit to one appearance of a given OID in oid_filters.
I guess it's implicit that there is no meaning to the order in which oid/values appear, and we don't need to say anything about that.

Revised text:
OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an  <ins> "unsupported_certificate" alert.  Any given OID MUST NOT appear more than once in the filters list. </ins> PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching
Original text:
%%% Record Layer <del> The TLSPLaintext.fragment value, containing the byte encoding of a </del>  handshake or an alert message, or the raw bytes of the application's data to send.

Reviewer comments:
I believe the markdown has not yet been sent to the RFC Editor, so we can save them the trouble by getting this in.

Revised text:
%%% Record Layer  <ins> The TLSPlaintext.fragment value, containing the byte encoding of a </ins> handshake or an alert message, or the raw bytes of the application's data to send.
Original text:
indicate which signature algorithms it can validate in X.509 certificates.  Additionally, this document clarifies some compliance requirements for earlier versions of TLS; see protocol-invariants. [[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]]  This document uses several registries that were originally created in RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are

Reviewer comments:
I wasn't sure where to put this text. There was an Appendix talking about TLS 1.2, so I figured it could go nearby. And then it probably wanted to go before that Appendix so there isn't ambiguity about how to refer to EMS.
Implementations of TLS 1.2 will remain for some time. The document renames "master secret" to "main secret", but TLS 1.2 has some naming variations that aren't in TLS 1.3. Perhaps a section in the document somewhere (maybe under Backward Compatibility since that talks about older versions) that describes some additional deltas: "master secret" => "main secret", to align this this document "premaster secret" => "preliminary secret" ("pre-main secret" sounds weird to me) "extended master secret" => "extended main secret" (probably move rfc7627 from informative to normative and then also add to the updates line) Also cover the variations like "EncryptedPreMasterSecret" and "mastersecret", but not the KDF labels since those can't change. And then IANA considerations to rename extendedmastersecret to extendedmain_secret in the registries.

Revised text:
indicate which signature algorithms it can validate in X.509 certificates. <ins> The term "master" as applied to secrets has been removed, and the "extended_master_secret" extension RFC7627 has been renamed to "extended_main_secret". </ins> Additionally, this document clarifies some compliance requirements for earlier versions of TLS; see protocol-invariants. [[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]] <ins> [[OPEN ISSUE: Add some text to rename the extended_master_secret entry in the extensions registry to extended_main_secret, after the above is resolved.]] </ins> This document uses several registries that were originally created in RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are
Original text:
over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. <del> This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations. </del>  1.

Reviewer comments:
The paragraph "This document supersedes and obsoletes previous" in the introduction also needs to be updated...

Revised text:
over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.  <ins> This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446.  This document also specifies new requirements for TLS 1.2 implementations. </ins> 1.
Original text:
contain all zero bits are stripped before it is used as the pre_master_secret. <del> Note: Diffie-Hellman parameters are specified by the server and may be either ephemeral or contained within the server's certificate. </del> 8.1.3. All ECDH calculations (including parameter and key generation as well

Reviewer comments:
This applies to TLS 1.3 draft 4. The ffdhe groups in Section 7.3.2.5.2 aren't up-to-date with draft-ietf-tls-negotiated-ff-dhe-04: ffdhe2432(256) has been replaced with ffdhe2048(256). ffdhe6144(259) is no more. ffdhe8192(260) has been renumbered to ffdhe8192(259). The note in Section 8.1.3 has text that refers to the old TLS 1.2 and earlier key exchange method, where the server could select any DH-parameters it liked. NamedGroup and NamedGroupList should be added to somewhere in appendix A.
Thanks. WRT to the appendix, I am going to let it get out of date for a draft or two and then do a mass update.
I am now auto-generating the appendix, so it will hopefully get less out of sync
Grubba, PTAL at the Pull Request above.
Looks good to me.
The latest FFDHE-draft (06) has reintroduced FFDHE-6144, and replaced FFDHE-2048 with FFDHE-2432, so this issue should probably be reopened.

Revised text:
contain all zero bits are stripped before it is used as the pre_master_secret.  8.1.3. All ECDH calculations (including parameter and key generation as well
Original text:
The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello <del> (pre-shared-key-extension).  Servers MAY send multiple tickets on a single connection, either immediately after each other or after </del>  specific events (see client-tracking).  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state.  Multiple

Reviewer comments:
Resumption before the initial connection is closed does not seem to be forbidden but RFC 8446 does not really give any answers. Oxford dictionary defines resumption as "the action of beginning something again after a pause or interruption." but I think "resumption" should just be seen as a slightly misleading name for the mechanism. RFC 8446 makes it clear that a connection can result in several tickets and that these tickets can be used in parallel with each other. My assumption would be that the tickets can also be used in parallel with the initial connection. If that is the case it would be good to state this. If not, it would be good to state that as well. The question came up in RFC6083bis where the suggestion is to set up parallel connections. I made a PR with the assumption that it’s allowed. I don’t see any reasons to forbid it, but I might miss something.
I concur that resumption should be permitted once the initial connection is established. I would prefer not to change the name, just because it's historically confusing not to.
Rich asked about SNI, but there are other values for extensions that might be included in a resumption handshake to cover the possibility that the session cannot be resumed. We should probably talk about that a little in the draft, maybe even throw a few "MUST" or "SHOULD" statements at it.
Resumption replaced by PSK so this is generally OBE.

Revised text:
The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello  <ins> (pre-shared-key-extension).  Resumption MAY be done while the original connection is still open.  Servers MAY send multiple tickets on a single connection, either immediately after each other or after </ins> specific events (see client-tracking).  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state.  Multiple
Original text:
value using: [sender] denotes the sending side.  The value of Secret for each <del> record type is shown in the table below. </del>  <del> All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). </del>  7.4.

Reviewer comments:
I cannot find any specification in RFC8446 of which key is used to encrypt an alert or heartbeat sent before Finished (I assume it is the applicationtrafficsecret). It is definitly possible that this information is somewhere in the document and that I just do not find it. The document seems to treat "record type" and "content type" as synonyms. Are both terms needed? I would suggest updating table in section 7.3 to make it complete. Record type "Application Data" should probably be everything that is not a Handshake. It would be good to say something about post-handshake messages in section 7.3. Post-handshake messages have record type/content type Handshake but does not follow what the table in 7.3 says.
The key is not specified as some errors can make it impossible for the peer to send an alert under specific key, so the used key is implicit—the currently used one, whichever it happens to be, including plaintext.
True, thank for reminding me. That is quite simple. Given that, I think the table in Section 7.3 is confusing and and not even correct. It claims to give the secret for each record type, but only lists 2. "0-RTT Application" is not a record type..... It gives the idea that the secret follows from the record type, which is not correct. It claims that record type Handshake is protected with [sender]handshaketraffic_secret, but record type handshake is protected with all three secrets depending on the state. I think it would probably be better to remove the table in 7.3 than to keep the current version. Even better would be to replace 7.3 with a more correct description.

Revised text:
value using: [sender] denotes the sending side.  The value of Secret for each  <ins> category of data is shown in the table below. </ins>  <ins> Alerts are sent with the then current sending key (or as plaintext if no such key has been established.)  All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). </ins> 7.4.
Original text:
with the new key.  Failure to do so may allow message truncation attacks.  5. The TLS record protocol takes messages to be transmitted, fragments

Reviewer comments:
Note that this is precisely the language that appears in 9147.
I made some updates, and am just merging in anticipation of the draft deadline. Feel free to file a PR if you think changes are indicated. NAME
In URL we added some text to DTLS about how rekeying too many times (2^64 is allowed with the 64-bit DTLS 1.3 epoch) risks key reuse within a connection, and accompanied it with a MUST NOT guidance to rekey more than 2^48 times (but receivers MUST NOT enforce the rule); this overrides the usual MUST-level requirement to match an "update_requested" KeyUpdate with another KeyUpdate before sending more data. It seems that some similar considerations apply for non-D TLS as well.

Revised text:
with the new key.  Failure to do so may allow message truncation attacks. <ins> With a 128-bit key as in AES-128, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated, so the chance of a joint key/IV collision is much lower.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch - and hence the number of key updates - to exceed 2^48-1.  In order to allow this value to be changed later - for instance for ciphers with more than 128-bit keys - receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits and SHOULD instead ignore the "update_requested" flag.  This may result in an eventual need to terminate the connection when the limits in limits-on-key-usage are reached. </ins> 5. The TLS record protocol takes messages to be transmitted, fragments
Original text:
handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more <del> appropriate.  This alert SHOULD be followed by a "close_notify". This alert generally has AlertLevel=warning. </del>  Either party MAY initiate a close of its write side of the connection <del> by sending a "close_notify" alert.  Any data received after a closure alert has been received MUST be ignored.  If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received. </del>  Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert.

Reviewer comments:
The new CFRG curves will probably have different point formats.
This was decided and will be handled as part of import

Revised text:
handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more  <ins> appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving implementations should continue to read data from the peer until a "close_notify" is received, though they MAY log or otherwise record them. </ins> Either party MAY initiate a close of its write side of the connection  <ins> by sending a "close_notify" alert.  Any data received after a "close_notify" alert has been received MUST be ignored.  If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received. </ins> Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert.
Original text:
result.  Received data is decrypted and verified, reassembled, and then delivered to higher-level clients. <del> Four protocols that use the record protocol are described in this </del>  document: the handshake protocol, the alert protocol, and the application data protocol.  In order to allow extension of the TLS protocol, additional record content types can be supported by the

Reviewer comments:
Four instead of three ? (hs, alert, app_data) Allusion to CCS ... ? Cheers, B.

Revised text:
result.  Received data is decrypted and verified, reassembled, and then delivered to higher-level clients.  <ins> Three protocols that use the record protocol are described in this </ins> document: the handshake protocol, the alert protocol, and the application data protocol.  In order to allow extension of the TLS protocol, additional record content types can be supported by the
Original text:
Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security <del> parameters given the options available.  This is a fatal error. </del>  This alert was used in SSLv3 but not any version of TLS.  It MUST

Reviewer comments:
I have seen multiple implementations with messages marked as warning instead of fatal.. It might be more explicit this way ? B.
I like this because some folks never read the text they just look at the code.

Revised text:
Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security  <ins> parameters given the options available.  This message is always fatal. </ins> This alert was used in SSLv3 but not any version of TLS.  It MUST
Original text:
There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.  AEAD-LIMITS provides an analysis of these limits under the assumption that the underlying <del> primitive (AES or ChaCha20) has no weaknesses.  Implementations SHOULD do a key update as described in key-update prior to reaching these limits.  Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data. </del>  For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of

Reviewer comments:
but tell receiving implementations not to enforce them. This addresses . NAME PTAL.
Limits on Key Usage (Section 5.5): Since key updates are necessary for security, I think MUST (rather than SHOULD) is appropriate. (And similarly in the sentence that follows: "Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data.")
IIRC there was a disagreement on when the rekeying should happen, and more specifically, the limits for Chacha20-Poly1305 are higher than the limit imposed by TLS sequence numbers, so there's no need to rekey if all you support is Chacha20...
NAME That seems compatible with MUST: Section 5.5 also notes: It follows that implementations might not do a key update.
I don't necessarily object to a MUST but I think as with the limit on KeyUpdate it would need to be paired with a MUST NOT enforce on the receiver. As I understand it, these bounds aren't necessarily tight, so we might have some results that allowed fewer rekeys in the future.

Revised text:
There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.  AEAD-LIMITS provides an analysis of these limits under the assumption that the underlying  <ins> primitive (AES or ChaCha20) has no weaknesses.  Implementations MUST either close the connection or do a key update as described in key- update prior to reaching these limits.  Note that it is not possible to perform a KeyUpdate for early data and therefore implementations MUST not exceed the limits when sending early data.  Receiving implementations SHOULD NOT enforce these limits, as future analyses may result in updated values. </ins> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of