jiebi/TextFlow huggingface dataset:
Original text:
11. <del> [[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]] [[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.]] </del> This document uses several registries that were originally created in <del> RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are below: </del>  TLS Cipher Suites registry: values with the first byte in the range 0-254 (decimal) are assigned via Specification Required value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition. 

Reviewer comments:
To keep the text in 8446bis and to avoid having people to read 8446 (and address the OPEN issues) in the IANA Considerations section - from IANA: If you want to keep the old actions in the document, we’d like to see those actions preceded by an introduction or sub-section (or more than one sub-section; however it’s appropriate to structure it) that tells us what the new actions are for this document.
The diffs are informative here - I think there's only adding general_error to TLS Alerts and updating the references to RFC 8446bis vice RFC 8446.
Apologies for any confusion - already address via .

Revised text:
11.  This document uses several registries that were originally created in  <ins> RFC4346 and updated in RFC8446 and RFC8447.  The changes between RFC8446 and RFC8447 this document are described in bis-changes.  IANA has updated these to reference this document. The registries and their allocation policies are below: </ins> TLS Cipher Suites registry: values with the first byte in the range 0-254 (decimal) are assigned via Specification Required value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition. <ins> 11.1. IANA [shall rename/has renamed] the "extended_master_secret" value in the TLS ExtensionType Values registry to "extended_main_secret". IANA [shall create/has created] a value for the "general_error" alert in the TLS Alerts Registry with the value given in alert-protocol. </ins>
Original text:
session not be resumed.  This is a change from TLS 1.0 to conform with widespread implementation practice. <del> Either party may initiate a close by sending a close_notify alert. </del>  Any data received after a closure alert is ignored. Unless some other fatal alert has been transmitted, each party is

Reviewer comments:
It refers to potentially sending a message so I would say its caps, though I am not sure about this one ...

Revised text:
session not be resumed.  This is a change from TLS 1.0 to conform with widespread implementation practice.  <ins> Either party MAY initiate a close by sending a close_notify alert. </ins> Any data received after a closure alert is ignored. Unless some other fatal alert has been transmitted, each party is
Original text:
"extension_data" contains information specific to the particular extension type. <del> The initial set of extensions is defined in a companion document TLSEXT.  The list of extension types is maintained by IANA as described in iana-considerations. </del>  An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello.  If a Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. <del> However, even if clients do offer it, the rules specified in TLSEXT </del>  require servers to ignore extensions they do not understand. Servers MUST NOT send this extension.  TLS servers MUST support restrictions) MUST be compatible with the selected key exchange algorithm. <del> The "server_name" and "trusted_ca_keys" extensions TLSEXT are used to guide certificate selection. </del>  If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/

Reviewer comments:
The TLS 1.2 RFC cited WIP extension definitions at time of publish. Update current draft to point the final RFC 6066.
URL Fix merged. This should be closable now.

Revised text:
"extension_data" contains information specific to the particular extension type.  <ins> The initial set of extensions is defined in RFC6066.  The list of extension types is maintained by IANA as described in iana- considerations. </ins> An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello.  If a Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions.  <ins> However, even if clients do offer it, the rules specified in RFC6066 </ins> require servers to ignore extensions they do not understand. Servers MUST NOT send this extension.  TLS servers MUST support restrictions) MUST be compatible with the selected key exchange algorithm.  <ins> The "server_name" and "trusted_ca_keys" extensions RFC6066 are used to guide certificate selection. </ins> If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/
Original text:
If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as if the client had sent value {sha1,ecdsa}. <del> Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA-1. </del> Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in RFC6066 signature algorithm pair that appears in that extension.  Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for <del> instance, an RSA key signed with a DSA key).  This is a departure from TLS 1.1, which required that the algorithms be the same. </del>  If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such

Reviewer comments:
These two notes are leftover from TLS 1.2 and not needed anymore in TLS 1.3. The first may not even be valid anymore.

Revised text:
If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as if the client had sent value {sha1,ecdsa}.  Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in RFC6066 signature algorithm pair that appears in that extension.  Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for  <ins> instance, an RSA key signed with a DSA key). </ins> If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such
Original text:
close_notify is more appropriate.  This alert should be followed by a close_notify.  This message is generally a warning. <del> no_renegotiation Sent by the client in response to a ServerHello or </del>  by the server in response to a ClientHello after initial handshaking. Versions of TLS prior to TLS 1.3 supported renegotiation of a previously established connection; TLS 1.3 removes this feature.

Reviewer comments:
Sorry 'bout all that me re-learning git again.
Assuming I've learned git properly, fixing the above should just be: git reset --hard HEAD~2 git push -f (done on this branch, of course; check branch log before pushing!)
Whenever you do a , always, ALWAYS specify a destination. You can be screwed by your config if you don't. The alternative is to do this: and open a new pull request. No force pushes that way (just a dead branch somewhere).

Revised text:
close_notify is more appropriate.  This alert should be followed by a close_notify.  This message is generally a warning.  <ins> no_renegotiation Sent by the client in response to a HelloRequest or </ins> by the server in response to a ClientHello after initial handshaking. Versions of TLS prior to TLS 1.3 supported renegotiation of a previously established connection; TLS 1.3 removes this feature.
Original text:
This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode CBCATT.  It MUST <del> NOT be sent by compliant implementations. </del>  A TLSCiphertext record was received that had a length more than This alert was used in previous versions of TLS.  TLS 1.3 does not include compression and TLS 1.3 implementations MUST NOT send this <del> alert when in TLS 1.3 mode. </del>  Reception of a "handshake_failure" alert message indicates that This alert was used in SSLv3 but not any version of TLS.  It MUST <del> NOT be sent by compliant implementations. </del>  A certificate was corrupt, contained signatures that did not This alert was used in some earlier versions of TLS.  It MUST NOT <del> be sent by compliant implementations. </del>  The protocol version the peer has attempted to negotiate is

Reviewer comments:
Expands on NAME improvements. The obsolete alerts were previously fatal and still are. Mark them as such. Also fix one of their names which is missing the "_RESERVED" in the descriptions list.

Revised text:
This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode CBCATT.  It MUST  <ins> NOT be sent by compliant implementations.  This message is always fatal. </ins> A TLSCiphertext record was received that had a length more than This alert was used in previous versions of TLS.  TLS 1.3 does not include compression and TLS 1.3 implementations MUST NOT send this  <ins> alert when in TLS 1.3 mode.  This message is always fatal. </ins> Reception of a "handshake_failure" alert message indicates that This alert was used in SSLv3 but not any version of TLS.  It MUST  <ins> NOT be sent by compliant implementations.  This message is always fatal. </ins> A certificate was corrupt, contained signatures that did not This alert was used in some earlier versions of TLS.  It MUST NOT  <ins> be sent by compliant implementations.  This message is always fatal. </ins> The protocol version the peer has attempted to negotiate is
Original text:
The record protection functions translate a TLSPlaintext structure into a TLSCiphertext.  The deprotection functions reverse the process.  In TLS 1.3 as opposed to previous versions of TLS, all <del> ciphers are modelled as "Authenticated Encryption with Additional </del>  Data" (AEAD) RFC5116.  AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. ClientHello. Servers MUST NOT send the EarlyData extension.  Negotiating TLS 1.3 <del> serves as acknowledgement that it was processed as described above. </del>  [[OPEN ISSUE: This is a fairly general mechanism which is possibly overkill in the 1-RTT case, where it would potentially be more

Reviewer comments:
(includes )
I'll let native speakers fix the typos next time xD
Your intuition on how to treat that last one was not wrong, but you need to know the specifics of the terminology to handle it properly. If that weren't a specific term, you'd have been correct, though usage of the word "compatible" there would've been strange. As to hyphenation, tech terminology turns hyphenated words into compound words way faster than natural language evolution. In other words, we tend to make up new words frequently and write them shorter each time. ;)
In my experience, native speakers are usually far from the best :)
Native speakers can muddle through free-form usage easily, so they don't notice how bad things might be to others. Non-native speakers can't intuitively piece together words as easily, and thus follow the rules more, which can be problematic because no verbal language actually follows its own rules fully, especially ones with lots of borrowed words. We all screw up language in different and interesting ways. :p I think a rebase is needed, as the whitespace changes were merged via your other PR. A squash of these commits into one to drop the reverted bits is probably a good idea, while you're at it.
Done, ready for merge... =)

Revised text:
The record protection functions translate a TLSPlaintext structure into a TLSCiphertext.  The deprotection functions reverse the process.  In TLS 1.3 as opposed to previous versions of TLS, all  <ins> ciphers are modeled as "Authenticated Encryption with Additional </ins> Data" (AEAD) RFC5116.  AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. ClientHello. Servers MUST NOT send the EarlyData extension.  Negotiating TLS 1.3  <ins> serves as acknowledgment that it was processed as described above. </ins> [[OPEN ISSUE: This is a fairly general mechanism which is possibly overkill in the 1-RTT case, where it would potentially be more
Original text:
11. Security issues are discussed throughout this memo, especially in <del> Appendices D, E, and F. </del>  12.

Reviewer comments:
Removal of the glossary re-assigned the appendix letters, so the ones referenced here are all one earlier.

Revised text:
11. Security issues are discussed throughout this memo, especially in  <ins> Appendices C, D, and E. </ins> 12.
Original text:
fatal. <del> This alert was used in SSLv3 but not any version of TLS.  It MUST NOT be sent by compliant implementations.  This message is always fatal. </del>  A certificate was corrupt, contained signatures that did not The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. <del> certificate_types has been present in TLS since SSLv3, but was </del>  somewhat underspecified.  Much of its functionality is superseded by supported_signature_algorithms.  The following rules apply: iana-considerations. Note: Values listed as RESERVED MUST NOT be used.  They were used in <del> SSLv3. </del>  Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.

Reviewer comments:
Small editorial change: The document currently goes back and forth between "SSLv3" & "SSL 3.0". Stick with the latter for consistency and clarity.

Revised text:
fatal.  <ins> This alert was used in SSL 3.0 but not any version of TLS.  It MUST NOT be sent by compliant implementations.  This message is always fatal. </ins> A certificate was corrupt, contained signatures that did not The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated.  <ins> certificate_types has been present in TLS since SSL 3.0, but was </ins> somewhat underspecified.  Much of its functionality is superseded by supported_signature_algorithms.  The following rules apply: iana-considerations. Note: Values listed as RESERVED MUST NOT be used.  They were used in  <ins> SSL 3.0. </ins> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.
Original text:
Remove support for MD5 and SHA-224 hashes with signatures.  draft-07 Integration of semi-ephemeral DH proposal. This is a list of the cryptographic options supported by the client, with the client's first preference first.  Values are <del> defined in the-cipher-suite. </del>  Versions of TLS before 1.3 supported compression and the list of In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher <del> suite TODO:Needs to be selected [1].  (See the-cipher-suite for the </del>  definition.) 9. 10. Security issues are discussed throughout this memo, especially in <del> Appendices C, D, and E. </del>  11.

Reviewer comments:
This revises "The Cipher Suites" section to simplify redundant language, actually explain the de facto naming convention, and add all currently available AEAD cipher suites. It also drops the appendix table that has already had its section whittled down quite a bit, in favor of the explanation and new table in the main section. Note that this is all of the AEAD ciphers available in the current IANA registry [0], plus ChaChaPoly (which has to be a normative reference [1], so must reach RFC status before this does). Issue just said "standards track AEAD ciphers", but as the registry lists them all, adding them wasn't difficult. If we'd rather not cite them here then they can of course be cut out (ARIA, Camellia, & ECDHE AES-CCM are informational; the rest are standards track, including DHE AES-CCM). Alternatively, the table could be annotated to note which are on what track or split in two. This has no changes to any requirements. [0] URL [1] URL
NAME I addressed your comments in this new commit. I switched to a table to make things easier to read and explicitly clarified the constant string bits so as to be more clear. I also dropped the confusing sentence fragment.
looks good.
AES-OCB will also be addable to this list, but its codepoints are all completely TBD still. URL
Rebased, squashed, & updated for recent changes to draft.
Ok, all comments addressed with that last commit. I've split the table into standards and non-standards and simplified the note to just mention ECDHE AES GCM being widely deployed.
Rebased.
Ok, reworded that bit too.
I only added the GCM AEAD ciphers. We should add all the standards track AEAD ciphers.
NAME This was dealt with in PR and can be closed.

Revised text:
Remove support for MD5 and SHA-224 hashes with signatures. <ins> Revise list of currently available AEAD cipher suites. </ins> draft-07 Integration of semi-ephemeral DH proposal. This is a list of the cryptographic options supported by the client, with the client's first preference first.  Values are  <ins> defined in cipher-suites. </ins> Versions of TLS before 1.3 supported compression and the list of In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher  <ins> suite TODO:Needs to be selected [1].  (See cipher-suites for the </ins> definition.) 9. 10. Security issues are discussed throughout this memo, especially in  <ins> Appendices B, C, and D. </ins> 11.
Original text:
HMAC(finished_secret, finished_label + '0' + handshake_hash) <del> where HMAC uses the Hash algorithm for the handshake.  See the- handshake-hash for the definition of handshake_hash. </del>  For Finished messages sent by the client, the string "client shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF. </del>  The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.

Reviewer comments:
Use refs for HKDF & HMAC in the document and drop the unused AES CBC RFC ref in favor of the AES GCM RFCs (refs already in use). Caught via Travis warnings that they were all unused. It also notes that RFC 2246 (TLS 1.0) isn't referenced directly and RFC 5705 isn't used, either. NAME You probably wanted to reference RFC 5705 somewhere in your recent work, but it's not currently used. Travis also complains about I-D.ietf-tls-session-hash, though that is referenced in the credits. It probably should be referenced somewhere too.
I've also added an update to the "obsoletes" line. We don't need to list TLS 1.1 (TLS 1.2 & 1.3 don't list 1.0), its extensions RFC, or AES CBC, as they've already been obsoleted by TLS 1.2 (also obsoleted old AES RFC) and the newer extensions RFC.

Revised text:
HMAC(finished_secret, finished_label + '0' + handshake_hash)  <ins> where HMAC RFC2104 uses the Hash algorithm for the handshake.  See the-handshake-hash for the definition of handshake_hash. </ins> For Finished messages sent by the client, the string "client shown below. The derivation process is as follows, where L denotes the length of  <ins> the underlying hash function for HKDF RFC5869. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.
Original text:
"NamedGroupList" value: %%% Named Group Extension enum { // Elliptic Curve Groups. <del> obsolete_RESERVED (1..13), sect571r1 (14), obsolete_RESERVED (15..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </del>  Indicates support of the corresponding named curve.  Note that

Reviewer comments:
It appears to be the consensus that sect571r1 should be dropped. This drops it and adds placeholders for the CFRG curves. There are likely to be more than these two values in the final version to indicate ECDHE & certificate usage separately.
NAME shall we remove sect571r1 Let's let the CFRG draft get a little further along before we add the placeholders.
On Wednesday, July 15, 2015 06:23:48 pm ekr wrote: Ok. I dropped that bit and pushed a new commit here.
Rob Stradling just posted to the list that he suspects that most users of this curve are just due to implementations blindly picking the biggest number, not because it was actually chosen. OpenSSL seems to do this by default and doesn't really provide an obvious way to change that.

Revised text:
"NamedGroupList" value: %%% Named Group Extension enum { // Elliptic Curve Groups.  <ins> obsolete_RESERVED (1..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </ins> Indicates support of the corresponding named curve.  Note that
Original text:
the certificate for future handshakes based on the CertificateRequest parameters supplied in this handshake.  The server MUST NOT send either of these two options unless it also <del> requested a certificate on this handshake [[OPEN ISSUE: Shoudl we relax this?]] </del>  This field is a placeholder for future extensions to the

Reviewer comments:
Consistently capitalize AEAD, fix a missing period, and fix a typo in a comment (for the sole purpose of appeasing my perfectionist tendencies ;).
I don't think changing aead-ciphered to AEAD-ciphered in the protocol description is an improvement. The typo fix is good :)
3 lines below aead-ciphered we have TLSCiphertext. Abbreviations are already kept in caps in almost every place. I don't see why it shouldn't be consistent and do so here as well.
I'd prefer to stay consistent with TLS 1.2.
Meh, ok. It looks out of place to me, but it's not a big deal. Commit revised to just fix the missing period and typo.

Revised text:
the certificate for future handshakes based on the CertificateRequest parameters supplied in this handshake.  The server MUST NOT send either of these two options unless it also  <ins> requested a certificate on this handshake.  [[OPEN ISSUE: Should we relax this?]] </ins> This field is a placeholder for future extensions to the