jiebi/CodeConvo huggingface dataset:
Change:
I think this aside is out-of-date: extensions cannot be empty, and there are now defined extensions to put here.

Discussion:
The version and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct <del> ClientHello pair (currently no such extensions exist).  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </del> <ins> ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </ins> Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake
Change:
NAME please double-check
URL The 1-RTT annotations are redundant and you also don't need [sender] in brackets because we can just fill in the values, as client/server have separate tables lines

Discussion:
The following table defines the Handshake Context and MAC Base Key for each scenario: <del> The [sender] in this table denotes the sending side. </del> In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type and length fields.
Change:
Fix a reference to a section that's directly citing a section number in plain text. (not linkified and will break if sections change) I assume this is a copy/paste error.

Discussion:
this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges <del> described in Section 4.5.2. </del> <ins> described in post-handshake-authentication. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any
Change:
The current text works, but tweaking it to be more general for issue is simple.
In the Client Hello (4.1.2) it says: As of TLS 1.3, all clients and servers will send at least one extension (at least "keyshare" or "presharedkey"). I believe that at least the supportedversions extension is also required for a client.
Rather than enumerating everything here, I've pushed a PR to just change "at least" to "e.g.".
I changed this separately.

Discussion:
optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined.  As of TLS 1.3, all clients and <del> servers will send at least one extension (at least "key_share" or </del> <ins> servers will send at least one extension (e.g. "key_share" or </ins> "pre_shared_key"). In previous versions of TLS, this field was used for version
Change:
and fix also not needed comma
:+1: was about to fix this too. Change was introduced by NAME in f6f752f9af24f99241ba98510cfb1dd758bf4bf9 (included with draft 16).
Hi, I have update the change !

Discussion:
TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to <del> include values for "end_of_early_data" and "missing_extension". </del> <ins> include values for "end_of_early_data", "missing_extension", and "certificate_required". </ins> TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this
Change:
I think this is a typo. But I'm not sure since I'm not a native English speaker. Please check it out.

Discussion:
The content to be signed This structure is intended to prevent an attack on previous versions <del> of previous versions of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen, 32-byte prefix.  The initial 64 byte pad clears that prefix. </del> <ins> of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen, 32-byte prefix. The initial 64 byte pad clears that prefix. </ins> The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client
Change:
TLSCiphertext.fragment is undefined. I guess it should be "TLSCiphertext.encrypted_record"? This sentence "due to the inclusion of URL and however much padding is supplied by the sender" is unclear to me. Does it mean "due to the inclusion of URL and the padding"?

Discussion:
The AEAD output consists of the ciphertext output by the AEAD encryption operation.  The length of the plaintext is greater than <del> TLSPlaintext.length due to the inclusion of TLSPlaintext.type and however much padding is supplied by the sender.  The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </del> <ins> TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any padding supplied by the sender.  The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, and the AEADEncrypted value.  The output is either the
Change:
When I was implementing the key schedule, it was unclear to me what stands for. This additional note would help other implementors. Kazuho Oku pointed out the similarity to Handshake Context. So, I updated that part, too.

Discussion:
In all cases, the handshake context is formed by concatenating the indicated handshake messages, including the handshake message type <del> and length fields. </del> <ins> and length fields, but not including record layer headers. </ins> 4.4.1.

functions defined below: The Hash function and the HKDF hash are the cipher suite hash <del> algorithm.  Hash.length is its output length. </del> <ins> algorithm.  Hash.length is its output length.  Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1,
Change:
Yes. There is a fair amount of other cleanup needed in this area; I have lots of red pen markings on a printout but haven't translated them into a patch yet.
Yes. There is a fair amount of other cleanup needed in this area; I have lots of red pen markings on a printout but haven't translated them into a patch yet.
Bah, github was angry-unicorning on me and did not indicate that the comment went through. I guess github doesn't like me this week...

Discussion:
ServerHello messages authenticates the protocol version, so this value is redundant. <del> The length (in bytes) of the following TLSCiphertext.fragment, which is the sum of the lengths of the content and the padding, plus one for the inner content type.  The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </del> <ins> The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type. The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </ins> The AEAD encrypted form of the serialized TLSInnerPlaintext structure.
Change:
Fix incorrect suggestion that of NST affects extension.
NAME merged. Please provide a PR adding yourself to the acknowledgements list in alphabetical order.

Discussion:
ticket_lifetime. A randomly generated 32-bit value that is used to obscure the age <del> of the ticket that the client includes in the "early_data" </del> <ins> of the ticket that the client includes in the "pre_shared_key" </ins> extension.  The client-side ticket age is added to this value modulo 2^32 to obtain the value that is transmitted by the client.
Change:
I forsee some merge conflicts in the future, as there's already and I have plans to rototill this section a bit more than you do here.
This won't conflict with . Git is good at detecting identical changes.

Discussion:
The plaintext is the concatenation of TLSPlaintext.fragment, TLSPlaintext.type, and any padding bytes (zeros). <del> The AEAD output consists of the ciphertext output by the AEAD </del> <ins> The AEAD output consists of the ciphertext output from the AEAD </ins> encryption operation.  The length of the plaintext is greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any padding supplied by the sender.  The length of the AEAD output will

If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert. <del> An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion of greater than 255 bytes.  An endpoint that receives a record from its </del> <ins> An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than 255 octets.  An endpoint that receives a record from its </ins> peer with TLSCipherText.length larger than 2^14 + 256 octets MUST terminate the connection with a "record_overflow" alert.  This limit is derived from the maximum TLSPlaintext length of 2^14 octets + 1

The sequence number is incremented after reading or writing each record.  The first record transmitted under a particular set of <del> traffic keys record key MUST use sequence number 0. </del> <ins> traffic keys MUST use sequence number 0. </ins> Sequence numbers do not wrap.  If a TLS implementation would need to wrap a sequence number, it MUST either rekey (key-update) or

TLSInnerPlaintext.content. The padding sent is automatically verified by the record protection <del> mechanism: Upon successful decryption of a TLSCiphertext.fragment, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet.  This non-zero octet is the content type of the message.  This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types.  The design also enforces all-zero padding octets, which allows for quick detection of padding errors. </del> <ins> mechanism: upon successful decryption of a TLSCiphertext.encrypted_record, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet.  This non-zero octet is the content type of the message.  This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types.  The design also enforces all-zero padding octets, which allows for quick detection of padding errors. </ins> Implementations MUST limit their scanning to the cleartext returned from the AEAD decryption.  If a receiving implementation does not
Change:
It could be just me, but the previous wording was kind of confusing (YMMV).

Discussion:
send this message when authenticating via a certificate.  Clients MUST send this message whenever authenticating via a Certificate (i.e., when the Certificate message is non-empty).  When sent, this <del> message MUST appear immediately after the Certificate Message and </del> <ins> message MUST appear immediately after the Certificate message and </ins> immediately prior to the Finished message. Structure of this message:

The digital signature is then computed using the signing key over the concatenation of: <del> 64 bytes of octet 32 </del> <ins> A string that consists of octet 32 (0x20) repeated 64 times </ins> The context string
Change:
The alert is described as being part of the first flight, but it is really sent when the server Finished is received, per the processing order section. Notably, servers MUST NOT wait for endofearlydata before sending ServerHello through Finished. Group it with the client Finished flight, and fix the text about it terminating the first flight. (The division between the first and second client flight isn't especially well-defined because early data may flow in parallel with the ServerHello flight. But if there is to be a division, endofearlydata certainly falls into the second one.)
Yes, this should help avoid one of the most common mistakes in 0-RTT implementations.
LGTM.

Discussion:
0-RTT messages sent in the first flight have the same content types as their corresponding messages sent in other flights (handshake, application_data, and alert respectively) but are protected under <del> different keys.  After all the 0-RTT application data messages (if any) have been sent, an "end_of_early_data" alert of type "warning" is sent to indicate the end of the flight.  0-RTT MUST always be followed by an "end_of_early_data" alert, which will be encrypted with the 0-RTT traffic keys. </del> <ins> different keys.  After receiving the server's Finished message, if the server has accepted early data, an "end_of_early_data" alert of type "warning" MUST be sent to indicate the key change.  This message will be encrypted with the 0-RTT traffic keys. </ins> A server which receives an "early_data" extension can behave in one of three ways:

This alert is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be <del> sent at all) and that this is the end of the flight.  This alert MUST be at the warning level.  Servers MUST NOT send this alert and clients receiving it MUST terminate the connection with an "unexpected_message" alert. </del> <ins> sent at all) and that the following records are protected under handshake traffic keys.  This alert MUST be at the warning level. Servers MUST NOT send this alert and clients receiving it MUST terminate the connection with an "unexpected_message" alert. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a
Change:
I found the wording a little hard to follow. This also by being very explicit about the presence of the change.
This changeset includes some "URL" cruft that isn't part of a reword.
In previous versions of TLS, passing no context was different to passing an empty context. TLS 1.3 doesn't distinguish between these. I don't know how important it is to highlight that minor difference, but it's probably worth mentioning.
So I should read more carefully: there is text about this, but it's not clear that this is a change from previous versions.

Discussion:
RFC5705 defines keying material exporters for TLS in terms of the TLS pseudorandom function (PRF).  This document replaces the PRF with HKDF, thus requiring a new construction.  The exporter interface <del> remains the same.  If context is provided, the value is computed as: </del> <ins> remains the same. The exporter value is computed as: </ins> Where Secret is either the early_exporter_secret or the exporter_secret.  Implementations MUST use the exporter_secret unless <del> explicitly specified by the application.  When adding TLS 1.3 to TLS 1.2 stacks, the exporter_secret MUST be for the existing exporter interface. If no context is provided, the value is computed as above but with a zero-length context_value.  Note that providing no context computes the same value as providing an empty context.  As of this document's publication, no allocated exporter label is used with both modes. Future specifications MUST NOT provide an empty context and no context with the same label and SHOULD provide a context, possibly empty, in all exporter computations. </del> <ins> explicitly specified by the application.  A separate interface for the early exporter is RECOMMENDED, especially on a server where a single interface can make the early exporter inaccessible. If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as providing an empty context.  This is a change from previous versions of TLS where an empty context produced a different output to an absent context.  As of this document's publication, no allocated exporter label is used both with and without a context.  Future specifications MUST NOT define a use of exporters that permit both an empty context and no context with the same label.  New uses of exporters SHOULD provide a context in all exporter computations, though the value could be empty. </ins> 8.
Change:
Most of these are simple enough, kramdown treats all bracketed text as a reference. So these can be replaced with and the warnings go away. The biggest change here is slightly stylistic: a few places had , which kramdown complained about, but rendered correctly. However, this produced a non-sentence. Also, I fixed some inconsistent use of references and s/data/date in one of the references.
See comment

Discussion:
The server processes the ClientHello and determines the appropriate cryptographic parameters for the connection.  It then responds with <del> its own ServerHello, which indicates the negotiated connection parameters. [server-hello].  The combination of the ClientHello and the ServerHello determines the shared keys.  If (EC)DHE key establishment is in use, then the ServerHello contains a "key_share" extension with the server's ephemeral Diffie-Hellman share which MUST be in the same group as one of the client's shares.  If PSK key establishment is in use, then the ServerHello contains a "pre_shared_key" extension indicating which of the client's offered PSKs was selected.  Note that implementations can use (EC)DHE and PSK together, in which case both extensions will be supplied. </del> <ins> its own ServerHello (server-hello), which indicates the negotiated connection parameters.  The combination of the ClientHello and the ServerHello determines the shared keys.  If (EC)DHE key establishment is in use, then the ServerHello contains a "key_share" extension with the server's ephemeral Diffie-Hellman share which MUST be in the same group as one of the client's shares.  If PSK key establishment is in use, then the ServerHello contains a "pre_shared_key" extension indicating which of the client's offered PSKs was selected.  Note that implementations can use (EC)DHE and PSK together, in which case both extensions will be supplied. </ins> The server then sends two messages to establish the Server Parameters:

to continue. Sent by a server in response to an invalid connection retry <del> attempt from a client. (see [RFC7507]) </del> <ins> attempt from a client RFC7507. </ins> Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version or
Change:
This is a redo of PR now that PR has removed the appending rule and resolved issue .

Discussion:
A list of offered KeyShareEntry values in descending order of client preference.  This vector MAY be empty if the client is <del> requesting a HelloRetryRequest.  The ordering of values here SHOULD match that of the ordering of offered support in the "supported_groups" extension. </del> <ins> requesting a HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order.  However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups. </ins> The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for.
Change:
Exporters and (EC)DHE secrets are not traffic secrets. Group the two (EC)DHE sections under a name which matches what the key schedule section calls it (the "(EC)DHE shared secret") and link to it from the key schedule.

Discussion:
PSK (a pre-shared key established externally or a resumption_master_secret value from a previous connection) <del> (EC)DHE shared secret </del> <ins> (EC)DHE shared secret (ecdhe-shared-secret-calculation) </ins> This produces a full key derivation schedule shown in the diagram below.  In this diagram, the following formatting conventions apply:

Secret changes (e.g., when changing from the handshake to application data keys or upon a key update). <del> 7.3.1. </del> <ins> 7.4. </ins> <del> A conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to byte string by encoding in big- endian, padded with zeros up to the size of the prime.  This byte string is used as the shared secret, and is used in the key schedule as specified above. </del> <ins> 7.4.1. For finite field groups, a conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to byte string by encoding in big-endian, padded with zeros up to the size of the prime.  This byte string is used as the shared secret, and is used in the key schedule as specified above. </ins> Note that this construction differs from previous versions of TLS which remove leading zeros. <del> 7.3.2. </del> <ins> 7.4.2. </ins> For secp256r1, secp384r1 and secp521r1, ECDH calculations (including parameter and key generation as well as the shared secret

For X25519 and X448, see RFC7748. <del> 7.3.3. </del> <ins> 7.5. </ins> RFC5705 defines keying material exporters for TLS in terms of the TLS pseudorandom function (PRF).  This document replaces the PRF with
Change:
Reading through the spec again I found a few tiny things to fix. I'm suggesting to replace "Zero-RTT" with "0-RTT" in the paragraph because I found "Zero-RTT" used only in headlines, but "0-RTT" consistently in paragraphs.
NAME Please provide a PR to add yourself to acknowledgements.

Discussion:
the server to allow the server to decline resumption and fall back to a full handshake, if needed.  The server responds with a "pre_shared_key" extension to negotiate use of PSK key establishment <del> and can (as shown here) to negotiate use of PSK key establishment and can (as shown here) respond with a "key_share" extension to do </del> <ins> and can (as shown here) respond with a "key_share" extension to do </ins> (EC)DHE key establishment, thus providing forward secrecy. When PSKs are provisioned out of band, the PSK identity and the KDF

The Server Name Indication (SNI), if any is to be used <del> As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </del> <ins> As shown in tls-0-rtt, the 0-RTT data is just added to the 1-RTT </ins> handshake in the first flight.  The rest of the handshake uses the same messages as with a 1-RTT handshake with PSK resumption.

the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. <del> Future extension or additions to the protocol may define new values. </del> <ins> Future extensions or additions to the protocol may define new values. </ins> Implementations need to be able to parse and ignore unknown values unless the definition of the field states otherwise.

extensions which are required to establish the cryptographic context.  Currently the only such extensions are "key_share" and "pre_shared_key".  All current TLS 1.3 ServerHello messages will <del> contain one of these two extensions. </del> <ins> contain one of these two extensions, or both when using a PSK with (EC)DHE key establishment. </ins> TLS 1.3 has a downgrade protection mechanism embedded in the server's random value.  TLS 1.3 servers which negotiate TLS 1.2 or below in