jiebi/CodeConvo huggingface dataset:
Change:
This follows naturally from the inclusion of EndOfEarlyData in the handshake transcript, but it doesn't hurt to mention it explicitly. See also, uh, 7511e2a259.
NAME I mention it explicitly because it tripped me up in implementation :)

Discussion:
%%% Updating Keys If the server sent an "early_data" extension, the client MUST send an <del> 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 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 derived from the client_early_traffic_secret. </del> <ins> EndOfEarlyData message after receiving the server Finished.  If the server does not send an "early_data" extension, then the client MUST NOT send an EndOfEarlyData message.  This message indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under 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 derived from the client_early_traffic_secret. </ins> 4.6.
Change:
There are a number of different alerts that may be suitable for sending to indicate a non-acceptable cert chain, e.g. certificaterevoked, certificateexpired, unknown_ca, etc. We should not restrict the client to only sending one specific alert.
I have updated this PR with the wording as suggested by NAME

Discussion:
algorithm only if the "signature_algorithms" extension provided by the client permits it.  If the client cannot construct an acceptable chain using the provided certificates and decides to abort the <del> handshake, then it MUST abort the handshake with an "unsupported_certificate" alert. </del> <ins> handshake, then it MUST abort the handshake with an appropriate certificate-related alert (by default, "unsupported_certificate"; see error-alerts for more). </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:
by Hugo Krawczyk.
Other than davegarrett's editorial notes, this looks good.

Discussion:
32 bytes generated by a secure random number generator.  See implementation-notes for additional information.  The last eight bytes MUST be overwritten as described below if negotiating TLS <del> 1.2 or TLS 1.1.  This structure is generated by the server and MUST be generated independently of the ClientHello.random. </del> <ins> 1.2 or TLS 1.1, but the remaining bytes MUST be random.  This structure is generated by the server and MUST be generated independently of the ClientHello.random. </ins> The single cipher suite selected by the server from the list in ClientHello.cipher_suites.  A client which receives a cipher suite

one for each potential PSK; if no PSK is selected, it will then need to compute the early secret corresponding to the zero PSK. <ins> Once all the values which are to be derived from a given secret have been computed, that secret SHOULD be erased. </ins> 7.2. Once the handshake is complete, it is possible for either side to
Change:
TLS 1.1 [RFC 4346] & TLS 1.2 [RFC 5246] each only have a list of changes from the immediately previous version. This current draft has both the current changelog since TLS 1.2 and the old list of changes from TLS 1.1 to 1.2. The contents of this old section are no longer relevant, in particular it mentions TLSRSAWITHAES128CBCSHA as MTI which is no longer permitted at all. Suggesting just removing this now.
Thanks. Merged.

Discussion:
Removed support for non-AEAD ciphers <del> 1.3. This document is a revision of the TLS 1.1 RFC4346 protocol which contains improved flexibility, particularly for negotiation of cryptographic algorithms.  The major changes are: The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs.  All cipher suites in this document use P_SHA256. The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash.  Signed elements now include a field that explicitly specifies the hash algorithm used. Substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept. Note that this also relaxes some of the constraints on signature and hash algorithms from previous versions of TLS. Addition of support for authenticated encryption with additional data modes. TLS Extensions definition and AES Cipher Suites were merged in from external TLSEXT and RFC3268. Tighter checking of EncryptedPreMasterSecret version numbers. Tightened up a number of requirements. Verify_data length now depends on the cipher suite (default is still 12). Cleaned up description of Bleichenbacher/Klima attack defenses. Alerts MUST now be sent in many cases. After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list. TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite. Added HMAC-SHA256 cipher suites. Removed IDEA and DES cipher suites.  They are now deprecated and will be documented in a separate document. Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOULD, with sending it a SHOULD NOT.  Support will probably become a SHOULD NOT in the future. Added limited "fall-through" to the presentation language to allow multiple case arms to have the same encoding. Added an Implementation Pitfalls sections The usual clarifications and editorial work. </del> 2. The goals of the TLS protocol, in order of priority, are as follows:
Change:
I disagree with this. Equally valid advice is to do as little as possible except abort the connection when receiving an alert. Some implementations will not send alerts at all.
NAME can you please raise this on the list in response to Kathleen's comments? Thanks
Per Kathleen's AD review

Discussion:
alert" and "abort the handshake with a X alert" mean that the implementation MUST send alert X if it sends any alert.  All alerts defined in this section below, as well as all unknown alerts, are <del> universally considered fatal as of TLS 1.3 (see alert-protocol). The following error alerts are defined: </del> <ins> universally considered fatal as of TLS 1.3 (see alert-protocol).  The implementation SHOULD provide a way to facilitate logging the sending and receiving of alerts. </ins> An inappropriate message (e.g., the wrong handshake message, premature application data, etc.) was received.  This alert should
Change:
The reference to [RFC7301] is after the third mention of ALPN. It should instead be at the first reference to ALPN.

Discussion:
The cipher suite for use with this PSK <del> The Application-Layer Protocol Negotiation (ALPN) protocol, if any is to be used </del> <ins> The Application-Layer Protocol Negotiation (ALPN) protocol RFC7301, if any is to be used </ins> The Server Name Indication (SNI), if any is to be used
Change:
NAME NAME I would appreciate a sanity check here.
Maybe remove the "arguably" statement and the *

Discussion:
Add a per-ticket nonce so that each ticket is associated with a different PSK (*). <ins> Clarify that clients should change to sending with handshake keys immediately upon reading ServerHello.  Arguably a wire format change. (*). Update state machine to show rekeying events </ins> Add discussion of 0-RTT and replay.  Recommend that implementations implement some anti-replay mechanism.

Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance <del> of either the peer's identity or of it's liveness (i.e., the </del> <ins> of either the peer's identity or of its liveness (i.e., the </ins> ClientHello might have been replayed). The key used to compute the finished message is computed from the
Change:
A straightforward cleanup of part of the backwards compatibility section. (handles an easy part of issue ) SSL 2.0 backwards compatibility was previously deprecated in TLS 1.2 (2008) and was warned to be "phased out with all due haste". RFC 6176 (2011) prohibits it entirely. It's a section of obsolete complexity still in the draft. Remove it and replace it with a simple "MUST NOT" send or accept. Edit to correct attribution of the "phased out with all due haste" language. Whilst in the TLS 1.2 (2008) spec, it was first introduced in SSL 3 (1996). It has been around for 19 years, not 5.
Dave, can you please post about this to the list?
I have to ask, why not SSL 3 as well?
This is about SSLv2 compatibility needing a different ClientHello format.
I completely agree that similar language should be added for SSL3 as well, however its prohibition RFC is not done yet. SSL2 was just an obvious start. I'll write another PR with the SSL3 prohibition draft language added in. URL
One possible idea if SSL 2.0 ClientHello compatibility is still needed is to max it at TLS 1.2.
There is discussion on list, but just let me say for the record here that I am astonished that this wasn't considered a non-controversial cleanup. The SSL2 hello has been deprecated for 20 years...
Per Brian's suggestion, this PR is now just for the changes with large agreement. Prohibiting all SSL v2 CLIENT-HELLO entirely is now moved to issue .
Per Brian's suggestion, splitting this off of PR . SSL v2 CLIENT-HELLO support requires additional implementation complexity that is an unnecessary risk to maintain support with a 20 year old deprecated negotiation format. Implementations have had notable bugs in handling this in the past. The current status quo expects them to be acceptable for negotiating TLS 1.0-1.2, even though ALL TLS clients are capable of using the SSL v3 version ClientHello if properly configured. Support for this has been optional and deprecated for many years, with the SSL 3 spec noting in 1996 that "The ability to send version 2.0 client hello messages will be phased out with all due haste. Implementers should make every effort to move forward as quickly as possible." Some implementers would be quite happy to have this prohibited entirely so that their code can finally be scrubbed clean of obsolete SSL 2 junk. Others want to perpetuate backwards compatibility support for EOL clients forever. I argue the former. A decision needs to be made on which path to chose. It will be depressing if it is to be the latter. :/
It is now no longer possible to use SSLv2 hellos with TLS 1.3 (because some extensions are mandatory) so we shouldn't need anythign here.

Discussion:
1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </ins> 1.2. <ins> draft-05 Prohibit SSL negotiation for backwards compatibility. </ins> draft-04 Remove renegotiation.
Change:
This is no longer a hash value throughout, using a different name might reduce confusion a little.
Seems like an improvement.+1

Discussion:
Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero- <del> length HashValue (indicated by "") is passed to HKDF-Expand-Label. </del> <ins> length Context (indicated by "") is passed to HKDF-Expand-Label. </ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.
Change:
Fix the spacing in and add it to Appendix B.3.1. Add missing space in .

Discussion:
For secp256r1, secp384r1 and secp521r1, the contents are the serialized value of the following struct: <ins> %%% Key Exchange Messages </ins> 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
Change:
The padding extension is typically computed as part of serializing the ClientHello, in hopes of targetting a particular size. As specified right now, the second ClientHello must not use this same logic and instead must retain the previous extension sizethough this would likely not hit the same target size. The server's going to ignore it anyway, so allow it to be recalcuated. This avoids unnecessary state in clients and extra logic to serialize the first and second ClientHellos differently.
Good catch; +1

Discussion:
removing any PSKs which are incompatible with the server's indicated cipher suite. <ins> Optionally adding, removing, or changing the length of the "padding" extension RFC7685. </ins> Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1.3 and receives a ClientHello at any other time, it MUST terminate the connection with an "unexpected_message" alert.
Change:
Currently, the draft says that servers MAY send multiple tickets to clients without further discussion. It might help to be concrete and provide an example for when more than one ticket is useful. This PR provides one example.

Discussion:
single connection, either immediately after each other or after specific events.  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the <del> additional client authentication state.  Clients SHOULD attempt to use each ticket no more than once, with more recent tickets being used first. </del> <ins> additional client authentication state.  Multiple tickets are useful for clients for a variety of purposes, including: Opening multiple parallel HTTP connections. Performing connection racing across interfaces and address families via, e.g., Happy Eyeballs RFC6555 or related techniques. Clients SHOULD attempt to use each ticket no more than once, with more recent tickets being used first. </ins> Any ticket MUST only be resumed on connections where the following values match the values negotiated in the connection during which the
Change:
The RFC editor found a few errors in a draft that used the same references. This updates the draft to use the automatically generated DOI references from URL rather than manual references. This isn't perfect, but it should help the RFC editor when it comes time to publish.
This changes: to LGTM (Dang is the author according to URL)

Discussion:
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 <del> Section 5.6.2.6 of KEYAGREEMENT.  This process consists of three </del> <ins> Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three </ins> 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
Change:
This is mentioned throughout the document, but not in the "Mandatory-to-Implement" section.
This is the same as , just without the extra new line additions, etc
In the section it states: In the section we have: However, this is not mentioned in the "Mandatory-to-Implement" extensions section.

Discussion:
All implementations MUST send and use these extensions when offering applicable features: <del> "supported_versions" is REQUIRED for all ClientHello messages. </del> <ins> "supported_versions" is REQUIRED for all ClientHello, ServerHello and HelloRetryRequest messages. </ins> "signature_algorithms" is REQUIRED for certificate authentication.
Change:
Without specifying the encoding, I don't think it's actually defined how you transit the certificates. RFC 5280 only says that the TBSCertificate is DER-encoded for computing the signature, which still allows insanity like XER-encoded everything with the receiver re-encoding the TBSCertificate to DER before verifying the signature.

Discussion:
If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not negotiated in Encrypted Extensions, or the X.509 certificate type was <del> 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. </del> <ins> negotiated, then each CertificateEntry contains a DER-encoded 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,
Change:
Server Hello is slightly confusing english. Must this be generated from the URL I'm pretty sure the opposite is the intent. A clearer form of words might be: or
Merged.

Discussion:
backward-compatibility for details about backward compatibility.) <del> This structure is generated by the server and MUST be independently generated from the ClientHello.random. </del> <ins> This structure is generated by the server and MUST be generated independently of the ClientHello.random. </ins> This is the identity of the session corresponding to this
Change:
RFC 8174 updates RFC 2119 so the boilerplate words have changed slightly according to s2 of RFC 8174. Just trying to save us another GENART comment.

Discussion:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> The following terms are used:
Change:
Issue 1: supportedversions is required in TLS 1.3 SH. Issue 2: supportedversions.selected_version must be identical in HRR and SH
NAME please submit a PR to add yourself to acknowledgements
Thanks for the fixup.

Discussion:
A list of extensions.  The ServerHello MUST only include extensions which are required to establish the cryptographic <del> context.  Currently the only such extensions are "key_share" and "pre_shared_key".  All current TLS 1.3 ServerHello messages will contain one of these two extensions, or both when using a PSK with (EC)DHE key establishment.  The remaining extensions are sent separately in the EncryptedExtensions message. </del> <ins> context and negotiate the protocol version.  All TLS 1.3 ServerHello messages MUST contain the "supported_versions" extension.  Current ServerHello messages contain either the "pre_shared_key" or "key_share" extensions, or both when using a PSK with (EC)DHE key establishment.  The remaining extensions are sent separately in the EncryptedExtensions message. </ins> For backward compatibility reasons with middleboxes (see middlebox) the HelloRetryRequest message uses the same structure as the

HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert. <ins> The value of selected_version in the HelloRetryRequest "supported_versions" extension MUST be retained in the ServerHello, and a client MUST abort the handshake with an "illegal_parameter" alert if the value changes. </ins> 4.2. A number of TLS messages contain tag-length-value encoded extensions
Change:
remove extra _ at the end of name -- the name in SignatureScheme enum lacks it

Discussion:
cipher suites.  (see cipher-suites) A TLS-compliant application MUST support digital signatures with <del> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256_ (for </del> <ins> rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for </ins> CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 RFC7748.
Change:
says: But the following text follows: MAY and MUST mismatch. Let's s/MUST/SHOULD/

Discussion:
This document describes TLS 1.3, which uses the version 0x0304.  This version value is historical, deriving from the use of 0x0301 for TLS 1.0 and 0x0300 for SSL 3.0.  In order to maximize backwards <del> compatibility, records containing an initial ClientHello MUST have </del> <ins> compatibility, records containing an initial ClientHello SHOULD have </ins> version 0x0301 and a record containing a second ClientHello or a ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.  When negotiating prior versions of TLS, endpoints
Change:
Previous PR plus some cleanup.
Looks good to me, for what it's worth :)
ekr: please merge this so we can get a new version out for the IESG.
NAME can you be more precise about the appendix D text? is the issue that we say "ignored" but then use it as additional_data?
NAME : PTAL

Discussion:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-25 - Add the header to additional data (*) Minor clarifications. IANA cleanup. </ins> draft-24 Require that CH2 have version 0303 (*)

The legacy_record_version field is always 0x0303.  TLS 1.3 TLSCiphertexts are not generated until after TLS 1.3 has been negotiated, so there are no historical compatibility concerns <del> where other values might be received.  Implementations MAY verify that the legacy_record_version field is 0x0303 and abort the connection if it is not.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </del> <ins> where other values might be received.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </ins> The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of

described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number (see nonce) and the client_write_iv or <del> server_write_iv, and the additional data input is empty (zero length).  Derivation of traffic keys is defined in traffic-key- calculation. </del> <ins> server_write_iv, and the additional data input is the record header. I.e., </ins> The plaintext input to the AEAD algorithm is the encoded <del> TLSInnerPlaintext structure. </del> <ins> TLSInnerPlaintext structure.  Derivation of traffic keys is defined in traffic-key-calculation. </ins> The AEAD output consists of the ciphertext output from the AEAD encryption operation.  The length of the plaintext is greater than

Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, <ins> Then the encrypted_record field of TLSCiphertext is set to AEADEncrypted. </ins> In order to decrypt and verify, the cipher takes as input the key, <del> nonce, and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the decryption failed.  There is no separate integrity check.  That is: </del> <ins> nonce, additional data, and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the decryption failed.  There is no separate integrity check.  That is: </ins> If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.