jiebi/CodeConvo huggingface dataset:
Change:
LGTM!
This is natural, since if you negotiate prior to 1.3 you must use the ServerHello rules for the negotiated URL

Discussion:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-26 - Clarify that you can't negotiate pre-TLS 1.3 with supported_versions. </ins> draft-25 - Add the header to additional data (*) Minor clarifications.

ClientHellos that include this extension but do not include 0x0304 in the list of versions. <del> A server which negotiates TLS 1.3 MUST respond by sending a "supported_versions" extension containing the selected version value (0x0304).  It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2).  Clients MUST check for this extension prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension).  If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version.  If the "supported_versions" extension contains a version not offered by the client, the client MUST abort the handshake with an "illegal_parameter" alert. </del> <ins> A server which negotiates a version of TLS prior to TLS 1.3 MUST set ServerHello.version and MUST NOT send the "supported_versions" extension.  A server which negotiates TLS 1.3 MUST respond by sending a "supported_versions" extension containing the selected version value (0x0304).  It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2).  Clients MUST check for this extension prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension).  If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version.  If the "supported_versions" extension contains a version not offered by the client or contains a version prior to TLS 1.3, the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 4.2.1.1.
Change:
PR for suggestion for issue .
Is this helping?
Glossaries are usually a good thing, but pretty much everything in there is either in need of pruning out or is better explained in its relevant section. The HTTP/2 spec just includes a really short glossary of basic terms up top: URL This seems like a better way to do this.
Not sure if this is the best route, but creating a PR for it was quick to do.
I'm in favor of removing the glossary. I don't think there's any need to explain what AES, DSA, etc. is in this document. Maybe it was needed when it first came out but it's not needed now. The only definition I thought might be needed is application layer/application layer protocol, but if you read s1 (right before where these terms will go) the concepts of layering on top of TLS is explained well enough in my mind. I could see adding a definition for "resumption" though.
Define resumption in-line with the text when it is first used, maybe. But I like Dave's change.
I can live with that too. Having it defined will hopefully stop these kind of things: URL
Merged.

Discussion:
"OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <ins> The following terms are used: client: The endpoint initiating the TLS connection. connection: A transport-layer connection between two endpoints. endpoint: Either the client or server of the connection. handshake: An initial negotiation between client and server that establishes the parameters of their transactions. peer: An endpoint.  When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion. receiver: An endpoint that is receiving records. sender: An endpoint that is transmitting records. session: An association between a client and a server resulting from a handshake. server: The endpoint which did not initiate the TLS connection. </ins> 1.2. draft-06
Change:
We currently have which is a little confusing, since it doesn't note that the server has the non-early exporter available once it has generated its first flight, and doubly so since the actual motivation for separate interfaces is for security reasons of not accidentally using the early exporter when the main one is needed. (Split out from )

Discussion:
exporter_master_secret unless explicitly specified by the application.  The early_exporter_master_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate <del> interface for the early exporter is RECOMMENDED. </del> <ins> interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </ins> If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as
Change:
I might do "both integers x and y" but I can see how it would be okay as-is.

Discussion:
%%% Key Exchange Messages <del> X and Y respectively are the binary representations of the X and Y </del> <ins> X and Y respectively are the binary representations of the x and y </ins> 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

take 48 octets each, and for P-521 they take 66 octets each. For the curves secp256r1, secp384r1 and secp521r1, peers MUST <del> validate each other's public value Y by ensuring that the point is a </del> <ins> validate each other's public value Q by ensuring that the point is a </ins> 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.3 of KEYAGREEMENT.  This process consists of three <del> steps: (1) verify that the point (X, Y) is not the point at infinity (O), (2) verify that both X and Y are integers in the correct interval, (3) ensure that (X, Y) is a correct solution to the elliptic curve equation.  For these curves, implementors do not need </del> <ins> 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 interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need </ins> to verify membership in the correct subgroup. For X25519 and X448, the contents of the public value are the byte
Change:
ClientHello, etc., processing rules are in earlier versions too. We're just calling out some corollaries of it all.

Discussion:
9.3. This section describes invariants that TLS endpoints and middleboxes <del> MUST follow.  It also applies to earlier versions, which assumed these rules but did not document them. </del> <ins> MUST follow.  It also applies to earlier versions of TLS. </ins> TLS is designed to be securely and compatibly extensible.  Newer clients or servers, when communicating with newer peers, should
Change:
We should say something about whether the same OID is allowed to appear multiple times in the oid_filters extension (and if it is, what the semantics are). Extracted from
As noted in my comments, there is a natural semantic for multiple, but it seems a bit silly. I think it would be fine to forbid them, though.
I think it's OK to limit to one appearance of a given OID in the oid_filters. (It probably does not matter much in terms of code complexity either way.)
I'm inclined to limit to one appearance of a given OID in oid_filters.
I guess it's implicit that there is no meaning to the order in which oid/values appear, and we don't need to say anything about that.

Discussion:
OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an <del> "unsupported_certificate" alert. </del> <ins> "unsupported_certificate" alert.  Any given OID MUST NOT appear more than once in the filters list. </ins> PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching
Change:
I believe the markdown has not yet been sent to the RFC Editor, so we can save them the trouble by getting this in.

Discussion:
%%% Record Layer <del> The TLSPLaintext.fragment value, containing the byte encoding of a </del> <ins> The TLSPlaintext.fragment value, containing the byte encoding of a </ins> handshake or an alert message, or the raw bytes of the application's data to send.
Change:
I wasn't sure where to put this text. There was an Appendix talking about TLS 1.2, so I figured it could go nearby. And then it probably wanted to go before that Appendix so there isn't ambiguity about how to refer to EMS.
Implementations of TLS 1.2 will remain for some time. The document renames "master secret" to "main secret", but TLS 1.2 has some naming variations that aren't in TLS 1.3. Perhaps a section in the document somewhere (maybe under Backward Compatibility since that talks about older versions) that describes some additional deltas: "master secret" => "main secret", to align this this document "premaster secret" => "preliminary secret" ("pre-main secret" sounds weird to me) "extended master secret" => "extended main secret" (probably move rfc7627 from informative to normative and then also add to the updates line) Also cover the variations like "EncryptedPreMasterSecret" and "mastersecret", but not the KDF labels since those can't change. And then IANA considerations to rename extendedmastersecret to extendedmain_secret in the registries.

Discussion:
indicate which signature algorithms it can validate in X.509 certificates. <ins> The term "master" as applied to secrets has been removed, and the "extended_master_secret" extension RFC7627 has been renamed to "extended_main_secret". </ins> Additionally, this document clarifies some compliance requirements for earlier versions of TLS; see protocol-invariants.

[[OPEN ISSUE: Should we remove this?  I am reluctant to create a situation where one needs to read 8446 to process this document.]] <ins> [[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.]] </ins> This document uses several registries that were originally created in RFC4346 and updated in RFC8447.  IANA has updated these to reference this document.  The registries and their allocation policies are
Change:
The paragraph "This document supersedes and obsoletes previous" in the introduction also needs to be updated...

Discussion:
over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. <del> This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations. </del> <ins> This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446.  This document also specifies new requirements for TLS 1.2 implementations. </ins> 1.
Change:
This applies to TLS 1.3 draft 4. The ffdhe groups in Section 7.3.2.5.2 aren't up-to-date with draft-ietf-tls-negotiated-ff-dhe-04: ffdhe2432(256) has been replaced with ffdhe2048(256). ffdhe6144(259) is no more. ffdhe8192(260) has been renumbered to ffdhe8192(259). The note in Section 8.1.3 has text that refers to the old TLS 1.2 and earlier key exchange method, where the server could select any DH-parameters it liked. NamedGroup and NamedGroupList should be added to somewhere in appendix A.
Thanks. WRT to the appendix, I am going to let it get out of date for a draft or two and then do a mass update.
I am now auto-generating the appendix, so it will hopefully get less out of sync
Grubba, PTAL at the Pull Request above.
Looks good to me.
The latest FFDHE-draft (06) has reintroduced FFDHE-6144, and replaced FFDHE-2048 with FFDHE-2432, so this issue should probably be reopened.

Discussion:
contain all zero bits are stripped before it is used as the pre_master_secret. <del> Note: Diffie-Hellman parameters are specified by the server and may be either ephemeral or contained within the server's certificate. </del> 8.1.3. All ECDH calculations (including parameter and key generation as well
Change:
Resumption before the initial connection is closed does not seem to be forbidden but RFC 8446 does not really give any answers. Oxford dictionary defines resumption as "the action of beginning something again after a pause or interruption." but I think "resumption" should just be seen as a slightly misleading name for the mechanism. RFC 8446 makes it clear that a connection can result in several tickets and that these tickets can be used in parallel with each other. My assumption would be that the tickets can also be used in parallel with the initial connection. If that is the case it would be good to state this. If not, it would be good to state that as well. The question came up in RFC6083bis where the suggestion is to set up parallel connections. I made a PR with the assumption that it’s allowed. I don’t see any reasons to forbid it, but I might miss something.
I concur that resumption should be permitted once the initial connection is established. I would prefer not to change the name, just because it's historically confusing not to.
Rich asked about SNI, but there are other values for extensions that might be included in a resumption handshake to cover the possibility that the session cannot be resumed. We should probably talk about that a little in the draft, maybe even throw a few "MUST" or "SHOULD" statements at it.
Resumption replaced by PSK so this is generally OBE.

Discussion:
The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello <del> (pre-shared-key-extension).  Servers MAY send multiple tickets on a single connection, either immediately after each other or after </del> <ins> (pre-shared-key-extension).  Resumption MAY be done while the original connection is still open.  Servers MAY send multiple tickets on a single connection, either immediately after each other or after </ins> specific events (see client-tracking).  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state.  Multiple
Change:
I cannot find any specification in RFC8446 of which key is used to encrypt an alert or heartbeat sent before Finished (I assume it is the applicationtrafficsecret). It is definitly possible that this information is somewhere in the document and that I just do not find it. The document seems to treat "record type" and "content type" as synonyms. Are both terms needed? I would suggest updating table in section 7.3 to make it complete. Record type "Application Data" should probably be everything that is not a Handshake. It would be good to say something about post-handshake messages in section 7.3. Post-handshake messages have record type/content type Handshake but does not follow what the table in 7.3 says.
The key is not specified as some errors can make it impossible for the peer to send an alert under specific key, so the used key is implicit—the currently used one, whichever it happens to be, including plaintext.
True, thank for reminding me. That is quite simple. Given that, I think the table in Section 7.3 is confusing and and not even correct. It claims to give the secret for each record type, but only lists 2. "0-RTT Application" is not a record type..... It gives the idea that the secret follows from the record type, which is not correct. It claims that record type Handshake is protected with [sender]handshaketraffic_secret, but record type handshake is protected with all three secrets depending on the state. I think it would probably be better to remove the table in 7.3 than to keep the current version. Even better would be to replace 7.3 with a more correct description.

Discussion:
value using: [sender] denotes the sending side.  The value of Secret for each <del> record type is shown in the table below. </del> <ins> category of data is shown in the table below. </ins> <del> All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). </del> <ins> Alerts are sent with the then current sending key (or as plaintext if no such key has been established.)  All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). </ins> 7.4.
Change:
Note that this is precisely the language that appears in 9147.
I made some updates, and am just merging in anticipation of the draft deadline. Feel free to file a PR if you think changes are indicated. NAME
In URL we added some text to DTLS about how rekeying too many times (2^64 is allowed with the 64-bit DTLS 1.3 epoch) risks key reuse within a connection, and accompanied it with a MUST NOT guidance to rekey more than 2^48 times (but receivers MUST NOT enforce the rule); this overrides the usual MUST-level requirement to match an "update_requested" KeyUpdate with another KeyUpdate before sending more data. It seems that some similar considerations apply for non-D TLS as well.

Discussion:
with the new key.  Failure to do so may allow message truncation attacks. <ins> With a 128-bit key as in AES-128, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated, so the chance of a joint key/IV collision is much lower.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch - and hence the number of key updates - to exceed 2^48-1.  In order to allow this value to be changed later - for instance for ciphers with more than 128-bit keys - receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits and SHOULD instead ignore the "update_requested" flag.  This may result in an eventual need to terminate the connection when the limits in limits-on-key-usage are reached. </ins> 5. The TLS record protocol takes messages to be transmitted, fragments
Change:
The function is defined using a function . URL This is presumably the KDF hash of the cipher suite, but this doesn't seem to be written down anywhere. The Key Schedule section says: URL I can't find corresponding text in the various other calls. We could define this globally in the Transcript Hash section, and indeed that fits with the claim that "In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash." But then we have another problem... The PSK binder is also defined in terms of Transcript-Hash. Like the other text, it does not define what Hash is. URL But the default definition doesn't work for the client, in two different ways: At the first ClientHello, the cipher suite hash algorithm isn't even known yet, so we cannot possibly use that one. At the second ClientHello, we have a cipher suite hash algorithm, but it may not necessarily match the PSK's one. To keep all everything injective, both need to be the PSK hash. Though this results in another subtlety which, while not ambiguous, maybe we should change: At the second ClientHello, there are two uses of Hash. There's the overall hash, which is stuck being the PSK one, and there's the funny . That one being the PSK's hash breaks the whole notion of the transcript being this append-only thing and is a huge pain. To compensate, we allowed the second ClientHello to . That works, but it's a pretty weird edge case and easily a source of bugs. What if we changed it to be the negotiated hash? It won't affect interop, since this PSK is guaranteed not to be negotiated. The client may as well fill in all zeros for the binder. It's also still injective, as long as everyone agrees that's the one we use. The transcript includes an unhashed HelloRetryRequest immediately after messagehash, so that fixes the choice of hash. (Plus we only have two hashes right now and they're different sizes...)

Discussion:
along with the new ClientHello.  For instance, if the client sends ClientHello1, its binder will be computed over: <del> Where Truncate() removes the binders list from the ClientHello. </del> <ins> Where Truncate() removes the binders list from the ClientHello.  Note that this hash will be computed using the hash associated with the PSK, as the client does not know which cipher suite the server will select. </ins> If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over:

hash computations.  Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash" <del> message, as described in the-transcript-hash. </del> <ins> message, as described in the-transcript-hash.  Note that the "message_hash" will be hashed with the negotiated function, which may or may match the hash associated with the PSK.  This is consistent with how the transcript is calculated for the rest of the handshake. </ins> 4.2.11.3.
Change:
The new CFRG curves will probably have different point formats.
This was decided and will be handled as part of import

Discussion:
handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more <del> appropriate.  This alert SHOULD be followed by a "close_notify". This alert generally has AlertLevel=warning. </del> <ins> appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving implementations should continue to read data from the peer until a "close_notify" is received, though they MAY log or otherwise record them. </ins> Either party MAY initiate a close of its write side of the connection <del> by sending a "close_notify" alert.  Any data received after a closure alert has been received MUST be ignored.  If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received. </del> <ins> by sending a "close_notify" alert.  Any data received after a "close_notify" alert has been received MUST be ignored.  If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received. </ins> Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert.
Change:
Four instead of three ? (hs, alert, app_data) Allusion to CCS ... ? Cheers, B.

Discussion:
result.  Received data is decrypted and verified, reassembled, and then delivered to higher-level clients. <del> Four protocols that use the record protocol are described in this </del> <ins> Three protocols that use the record protocol are described in this </ins> document: the handshake protocol, the alert protocol, and the application data protocol.  In order to allow extension of the TLS protocol, additional record content types can be supported by the
Change:
I have seen multiple implementations with messages marked as warning instead of fatal.. It might be more explicit this way ? B.
I like this because some folks never read the text they just look at the code.

Discussion:
Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security <del> parameters given the options available.  This is a fatal error. </del> <ins> parameters given the options available.  This message is always fatal. </ins> This alert was used in SSLv3 but not any version of TLS.  It MUST