jiebi/CodeConvo huggingface dataset:
Change:
FIPS 186-4 is obsolete Curve definitions have moved to the new NIST SP 800-186 ANSI X9.62 is behind a paywall and should be avoided if possible. References behind paywall can not be accessed by most readers. This makes it harder to implement and to evaluate the security of the protocol. FIPS 186-5 removed the dependency on ANSI X9.62 and defines ECDSA itself. Point validation is defined in the new NIST SP 800-186.

Discussion:
Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA <del> RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) ECDSA, </del> <ins> RSA, the Elliptic Curve Digital Signature Algorithm (ECDSA) DSS, </ins> or the Edwards-Curve Digital Signature Algorithm (EdDSA) RFC8032) or a symmetric pre-shared key (PSK).

"signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. <del> Indicates a signature algorithm using ECDSA ECDSA, the corresponding curve as defined in ANSI X9.62 ECDSA and FIPS 186-4 DSS, and the corresponding hash algorithm as defined in SHS.  The signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. </del> <ins> Indicates a signature algorithm using ECDSA DSS, the corresponding curve as defined in NIST SP 800-186 ECDP, and the corresponding hash algorithm as defined in SHS.  The signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. </ins> Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest

%%% Supported Groups Extension Indicates support for the corresponding named curve, defined in <del> either FIPS 186-4 DSS or in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for Private Use RFC8126. </del> <ins> either NIST SP 800-186 ECDP or in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for Private Use RFC8126. </ins> Indicates support for the corresponding finite field group, defined in RFC7919.  Values 0x01FC through 0x01FF are reserved for

For the curves secp256r1, secp384r1, and secp521r1, peers MUST validate each other's public value Q by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation <del> procedures are defined in Section 4.3.7 of ECDSA and alternatively in </del> <ins> procedures are defined in Appendix D.1 of ECDP and alternatively in </ins> Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three 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
Change:
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.

Discussion:
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> <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
Change:
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 .

Discussion:
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> <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>
Change:
It refers to potentially sending a message so I would say its caps, though I am not sure about this one ...

Discussion:
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> <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
Change:
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.

Discussion:
"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> <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. <del> However, even if clients do offer it, the rules specified in TLSEXT </del> <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. <del> The "server_name" and "trusted_ca_keys" extensions TLSEXT are used to guide certificate selection. </del> <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/
Change:
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.

Discussion:
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> <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
Change:
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).

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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 <del> alert when in TLS 1.3 mode. </del> <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 <del> NOT be sent by compliant implementations. </del> <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 <del> be sent by compliant implementations. </del> <ins> be sent by compliant implementations.  This message is always fatal. </ins> The protocol version the peer has attempted to negotiate is
Change:
(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... =)

Discussion:
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> <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 <del> serves as acknowledgement that it was processed as described above. </del> <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
Change:
Small editorial change: The document currently goes back and forth between "SSLv3" & "SSL 3.0". Stick with the latter for consistency and clarity.

Discussion:
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> <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. <del> certificate_types has been present in TLS since SSLv3, but was </del> <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 <del> SSLv3. </del> <ins> SSL 3.0. </ins> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.
Change:
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.

Discussion:
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 <del> defined in the-cipher-suite. </del> <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 <del> suite TODO:Needs to be selected [1].  (See the-cipher-suite for the </del> <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 <del> Appendices C, D, and E. </del> <ins> Appendices B, C, and D. </ins> 11.
Change:
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.

Discussion:
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> <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 <del> the underlying hash function for HKDF. </del> <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.
Change:
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.

Discussion:
"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> <ins> obsolete_RESERVED (1..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </ins> Indicates support of the corresponding named curve.  Note that
Change:
As discussed on list.
Minor suggestions: 1) Explicitly specify the expectation of a "record_overflow" alert after the two "MUST NOT"s. 2) Also drop the issue "OPEN ISSUE" note that's on line 1087-1088. 3) Amend the changelog to mention this. 4) Add a sentence noting the overhead cap has changed to the "Note: In versions of TLS prior to 1.3" paragraph, or elsewhere.
As NAME suggests, I've updated the PR. I have not added the Note. I don't like those. The change log is enough.
Why was the changelog amended as for draft-09? The draft-08 hasn't been published yet. Is it in the progress of being released? (not shown on DataTracker and releases haven't been tagged on GitHub since draft-05)
Pilot error. Please feel free to submit a PR. , Dave Garrett EMAIL wrote:
This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later. This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.
Proposal at interim: 256 octets total.

Discussion:
1.2. <ins> draft-09 The maximum permittion record expansion for AEAD has been reduced from 2048 to 256 octets. </ins> draft-08 Remove support for weak and lesser used named curves.

The length (in bytes) of the following TLSCiphertext.fragment. <del> The length MUST NOT exceed 2^14 + 2048. </del> <ins> The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST generate a fatal "record_overflow" alert. </ins> The AEAD encrypted form of TLSPlaintext.fragment.

encryption operation.  The length will generally be larger than TLSPlaintext.length, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of <del> overhead could vary with different TLSPlaintext.length values.  Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. </del> <ins> overhead could vary with different TLSPlaintext.length values. </ins> Symbolically, <del> [[OPEN ISSUE: Reduce these values? https://github.com/tlswg/tls13- spec/issues/55]] </del> In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the

If the decryption fails, a fatal "bad_record_mac" alert MUST be generated. <ins> An AEAD cipher MUST NOT produce an expansion of greater than 256 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 cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL

A TLSCiphertext record was received that had a length more than <del> 2^14+2048 bytes, or a record decrypted to a TLSPlaintext record </del> <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).