jiebi/CodeConvo huggingface dataset:
Change:
minor additions, the context string wasn't explained anywhere as well so I thought a mini-line would help.

Discussion:
This structure is intended to prevent an attack on previous versions of TLS in which the ServerKeyExchange format meant that attackers <del> could obtain a signature of a message with a chosen, 32-byte prefix. The initial 64 byte pad clears that prefix. </del> <ins> could obtain a signature of a message with a chosen 32-byte prefix (ClientHello.random).  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 <del> CertificateVerify". </del> <ins> CertificateVerify".  It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. </ins> For example, if Hash(Handshake Context + Certificate) was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by
Change:
This is a giant pile of nitpicks, loosely inspired by the FFDHE alert discussion. The old text specifies a handshakefailure which is redundant with and contradicts the Cryptographic Negotiation section. The old text says only handshakefailure is allowed while Cryptographic Negotiation allows both handshakefailure and insufficientsecurity. Fix this by avoiding redundancy as the failure cases are global to the overall negotiation algorithm. Next, align the tense with itself and the rest of the text. Most of the text appears to be written in present tense. The old text for SH said: The server will send [...] when it was able to [...] which is a little odd. Also align the wording between the two. Talk about a server (singular) to match Cryptographic Negotiation and say "parameters" rather than "algorithms" or "algorithms and groups". Also be consistent about the SH vs. HRR condition. The SH section said "the client’s key_share extension was acceptable" while the HRR section said "the client’s ClientHello did not contain sufficient information to proceed with the handshake". Use the more general one.
Seems reasonable. I a little bit wondered whether to replace "it" with "the server", but the pronoun's meaning should be clear, here.
Seems clear enough to me, but I'm equally happy with the other wording. shrug
This does seem clearer. And shorter!

Discussion:
4.1.3. The server will send this message in response to a ClientHello <del> message when it was able to find an acceptable set of algorithms and the client's "key_share" extension was acceptable.  If it is not able to find an acceptable set of parameters, the server will respond with a "handshake_failure" fatal alert. </del> <ins> message if it is able to find an acceptable set of parameters and the ClientHello contains sufficient information to proceed with the handshake. </ins> Structure of this message:

4.1.4. <del> Servers send this message in response to a ClientHello message if they were able to find an acceptable set of algorithms and groups that are mutually supported, but the client's ClientHello did not contain sufficient information to proceed with the handshake.  If a server cannot successfully select algorithms and groups, it MUST abort the handshake with a "handshake_failure" alert. </del> <ins> The server will send this message in response to a ClientHello message if it is able to find an acceptable set of parameters but the ClientHello does not contain sufficient information to proceed with the handshake. </ins> Structure of this message:
Change:
Per the recent thread. I could have sworn this was in here, but can't find it... The NewSessionTicket section explicitly says to ignore unknown extensions, so I've added the analogous text to ClientHello and CertificateRequest.

Discussion:
data in the extensions field.  The actual "Extension" format is defined in extensions.  In TLS 1.3, use of certain extensions is mandatory, as functionality is moved into extensions to preserve <del> ClientHello compatibility with previous versions of TLS. </del> <ins> ClientHello compatibility with previous versions of TLS.  Servers MUST ignore unrecognized extensions. </ins> In the event that a client requests additional functionality using extensions, and this functionality is not supplied by the server, the

An optional set of extensions describing the parameters of the certificate being requested.  The "signature_algorithms" extension <del> MUST be specified. </del> <ins> MUST be specified.  Clients MUST ignore unrecognized extensions. </ins> In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the
Change:
Add reference to label format in 5705. address issue
refer the reader to exporter requirements in RFC 5705 "Requirements for the format of Exporter labels are defined in section 4 of RFC5705." Creating pull request.
NAME should we expect a PR?
This appears to be done.
yes I submitted PR which has been merged already.

Discussion:
exporters SHOULD provide a context in all exporter computations, though the value could be empty. <ins> Requirements for the format of exporter labels are defined in section 4 of RFC5705. </ins> 8. 8.1.
Change:
benefits: (1) Restoring extract/expand parity, thus cleaning up the theoretical treatment wrt HKDF and future replacements. (2) Futureproofing against someone being able to force the ECDHE value in the second HKDF-Extract to collide with one of the labels. This seems unlikely with current groups, but might be possible with some future algorithm. (Issue due to Trevor Perrin).
This is mostly a cosmetic thing, and I'm not sure if I actually like all of my proposals below: With the current scheme, the key schedule is very simple and neatly encompassed into a box with a shape like this: NewTLS13KeySchedule(hash) => creates a new schedule with base secret = 0 AddEntropy(sched, ikm) => HKDF-Extract ikm into the current base secret DeriveSecret(sched, label) => take the current base secret and handshake transcript and derive a particular secret with the label This breaks the symmetry in a few ways: Incorporating a new IKM requires an extra label for the Derive-Secret operation in the middle. Going from 0 to Early Secret does not involve a Derive-Secret. We use Derive-Secret, Derive-Secret no longer always uses the current state of the handshake transcript (1) could be resolved by just using the same label for both, like "prepare extract" or something. I don't believe this breaks anything? We're just trying to fix the problem where HKDF-Extract and HKDF-Expand can't be used on the same key. (3) is actually kind of odd because Derive-Secret is defined as: Derive-Secret(Secret, Label, Messages) = HKDF-Expand-Label(Secret, Label, Hash(Messages), Hash.Length) So we're actually putting Hash("") into HKDF-Expand-Label, not the empty string. Then again, it feels odd making them ClientHello...ServerHello and ClientHello...Server Finished, respectively. We could use HKDF-Expand-Label directly which still gives us the separation, but it's not as obvious. Adding an extra Derive-Secret just to fix (2) feels a little pointless but would increase symmetry. (Alternatively, the answer could just be "deal with it, your key schedule box should have slightly richer methods on it". Like I said, this is just cosmetic.)
I'm ambivalent on David's gripe. This seems fine to me. One editorial suggestion though. This is now a very tall diagram. You can save a few lines by changing to something like this
About this PR, there is a con: complicating the already complicated key schedule
It does not seem especially complicated compared to, e.g., Kerberos. Or maybe that's just me.
well, you're comparing it to Kerberos :rofl:
NAME I fixed . I think we can live without . We already have this "empty hash" construct for the binder keys, so while it's a bit goofy it's no more goofy than here.
We seem to have reached consensus that the record layer will use the AEAD form only. The stream and CBC forms will be removed.
Fixed.

Discussion:
Change end_of_early_data to be a handshake message (*). <ins> Add pre-extract Derive-Secret stages to key schedule (*). </ins> Remove spurious requirement to implement "pre_shared_key". Clarify location of "early_data" from server (it goes in EE, as
Change:
I wonder why this was only a before. Am I right to assume that this is because TLS 1.3 has removed support for static DH and leaking an ephemeral key is not considered to be a security problem?
Gotta say, I don't know why this was SHOULD. That check is very easy to implement.
says .
This text was adapted from some old draft of 7919 which had should and never got updated (see for instance: URL). Good catch.
NAME Please provide a PR adding yourself to contributors.

Discussion:
Note: For a given Diffie-Hellman group, the padding results in all public keys having the same length. <del> Peers SHOULD validate each other's public key Y by ensuring that 1 < Y < p-1.  This check ensures that the remote peer is properly behaved </del> <ins> Peers MUST validate each other's public key Y by ensuring that 1 < Y < p-1.  This check ensures that the remote peer is properly behaved </ins> and isn't forcing the local system into a small subgroup. 4.2.5.2.
Change:
An EndOfEarlyData message signals a key change. A ClientHello can be the last message read before a key is changed, and it never makes sense for a ClientHello to have more data after it in the record.

Discussion:
records, there MUST NOT be any other records between them. Handshake messages MUST NOT span key changes.  Because the <del> ServerHello, Finished, and KeyUpdate messages signal a key change, upon receiving these messages a receiver MUST verify that the end of these messages aligns with a record boundary; if not, then it MUST terminate the connection with an "unexpected_message" alert. </del> <ins> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can arrive immediately prior to a key change, upon receiving these messages a receiver MUST verify that the end of these messages aligns with a record boundary; if not, then it MUST terminate the connection with an "unexpected_message" alert. </ins> Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.
Change:
client to implement because it knows what hash the server will select. Also clarify the language about HRR and Key Shares.
NAME is this what you had in mind?
I did consider bogus binders, but dropping seems more sensible, and it seems like the only impact of the bogus binder would be that if the server didn't follow a consistent rule, then you would get a handshake failure at the server. It's not like it could pick them in any case.
(Agreed. This version feels way less weird.)
NAME comments welcome

Discussion:
%%% Key Exchange Messages <del> The server_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 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. </del> <ins> The version, cipher_suite, 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 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

key_share (see key-share) <ins> In addition, in its updated ClientHello, the client SHOULD NOT offer any pre-shared keys associated with a hash other than that of the selected cipher suite.  This allows the client to avoid having to compute partial hash transcripts for multiple hashes in the second ClientHello.  A client which receives a cipher suite that was not offered MUST abort the handshake.  Servers MUST ensure that they negotiate the same cipher suite when receiving a conformant updated ClientHello (if the server selects the cipher suite as the first step in the negotiation, then this will happen automatically).  Upon receiving the ServerHello, clients MUST check that the cipher suite supplied in the ServerHello is the same as that in the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert. </ins> 4.2. A number of TLS messages contain tag-length-value encoded extensions

KeyShareEntry for any group not indicated in the "supported_groups" extension and MUST NOT send a KeyShareEntry when using the "psk_ke" PskKeyExchangeMode.  If a HelloRetryRequest was received by the <del> client, the client MUST verify that the selected NamedGroup matches one that the client sent in its supported_groups extension and MUST abort the handshake with an "illegal_parameter" alert otherwise. </del> <ins> client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the HelloRetryRequest.  If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 4.2.5.1.
Change:
I think this addresses the issue raised by Russ Housley without changing the semantics of the protocol.
I will give a post-merge "seems fine", since I was so vocal in trying to nail down what Russ wanted.
Mentions of non-existent yet RFCs look weird to me but heh

Discussion:
When (EC)DHE is in use, the server will also provide a "key_share" extension. <del> When authenticating via a certificate (i.e., when a PSK is not in use), the server will send the Certificate (certificate) and CertificateVerify (certificate-verify) messages. </del> <ins> When authenticating via a certificate, the server will send the Certificate (certificate) and CertificateVerify (certificate- verify) messages.  In TLS 1.3 as defined by this document, either a PSK or a certificate is always used, but not both.  Future documents may define how to use them together. </ins> If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters),
Change:
…appens rather than on receipt of handshake messages. It is only actually necessary to verify that a handshake message aligns with a key change when changing keys, not when receiving the message, and it can be simpler to implement the check in this way. This change requires senders to align all these messages with a record boundary as before, but only requires recipients to verify the record boundary when the key change actually happens.

Discussion:
types.  That is, if a handshake message is split over two or more records, there MUST NOT be any other records between them. <del> Handshake messages MUST NOT span key changes.  Because the </del> <ins> Handshake messages MUST NOT span key changes.  Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert.  Because the </ins> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate <del> messages can arrive immediately prior to a key change, upon receiving these messages a receiver MUST verify that the end of these messages aligns with a record boundary; if not, then it MUST terminate the connection with an "unexpected_message" alert. </del> <ins> messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary. </ins> Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.
Change:
31f836238e5968a85c9e4d64d8ab23c0bbed8061 missed a spot.
NAME
:+1: Having a definition on when EOED must be sent is good for both interoperability and as a guildeline of how 0RTT support should be implemented.

Discussion:
%%% Updating Keys <del> The EndOfEarlyData message is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be sent at all) and that the following records are protected under </del> <ins> If the server sent an "early_data" extension, the client MUST send an EndOfEarlyData after receiving the server Finished.  This indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under </ins> handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert.  This message is encrypted under keys
Change:
Explicitly define RFC 7250 certificate support.
Seems reasonable. (I did not try to audit the rest of the text to see if there are other places that need updating.)
This captures what we talked about in Chicago.
Shucks, this hasn't landed yet, so I'll have to remember to update my editorial changes pull request that puts the numbers for these into the enumerated type definition for extensions.

Discussion:
case of server authentication), this field SHALL be zero length. This is a sequence (chain) of CertificateEntry structures, each <del> containing a single certificate and set of extensions.  The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> containing a single certificate and set of extensions. </ins> A set of extension values for the CertificateEntry.  The "Extension" format is defined in extensions.  Valid extensions

applies to the entire chain, it SHOULD be included in the first CertificateEntry. <ins> If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not used or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate.  The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify one preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility.  Servers sometimes

TLS version, with the exception of the end-entity certificate which MUST be first. <ins> If the RawPublicKey certificate type was negotiated, then the certificate_list MUST contain no more than one CertificateEntry, which contains an ASN1_subjectPublicKeyInfo value as defined in RFC7250, Section 3. </ins> The server's certificate_list MUST always be non-empty.  A client will send an empty certificate_list if it does not have an appropriate certificate to send in response to the server's
Change:
be unpredictable in order to prevent pre-computation of CertificateVerify. Maybe this should actually be a MUST?
Note: an attacker can of course forge a complete handshake but maybe for some quirk of the environment that's not as good.

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 post-handshake-authentication. </del> <ins> described in post-handshake-authentication.  When requesting post- handshake authentication, the server SHOULD make the context unpredictable to the client (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the client's private key from pre-computing valid CertificateVerify messages. </ins> A set of extensions describing the parameters of the certificate being requested.  The "signature_algorithms" extension MUST be
Change:
As suggested by Nikos, provide a formal description of the point format modelled on 4492-bis.
Per Nikos's comment.

Discussion:
ECDHE parameters for both clients and servers are encoded in the the opaque key_exchange field of a KeyShareEntry in a KeyShare structure. <del> For secp256r1, secp384r1 and secp521r1, the contents are the byte string representation of an elliptic curve public value following the conversion routine in Section 4.3.6 of ANSI X9.62 X962. Although X9.62 supports multiple point formats, any given curve MUST specify only a single point format.  All curves currently specified in this document MUST only be used with the uncompressed point format (the format for all ECDH functions is considered uncompressed). Peers MUST validate each other's public value Y by ensuring that the point is a valid point on the elliptic curve. For the curves secp256r1, secp384r1 and secp521r1, the appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.6 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers 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 to verify membership in the correct subgroup. </del> <ins> For secp256r1, secp384r1 and secp521r1, the contents are the serialized value of the following struct: X and Y respectively are the binary representations of the X and Y 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 32 octets, padded on the left by zeros if necessary.  For P-384 they take 48 octets each, and for P-521 they take 66 octets each. For the curves secp256r1, secp384r1 and secp521r1, peers MUST validate each other's public value Y by ensuring that the point is a 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.6 of KEYAGREEMENT.  This process consists of three steps: (1) verify that Y is not the point at infinity (O), (2) verify that for Y = (x, y) both integers 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 to verify membership in the correct subgroup. </ins> For X25519 and X448, the contents of the public value are the byte string inputs and outputs of the corresponding functions defined in