jiebi/CodeConvo huggingface dataset:
Change:
Avoid both starting with an existing hash AND ending with an existing SignatureAlgorithm. In principle, this should not be necessary, but TLS says: Bouncy Castle appears to have been enforcing this, causing interop issues. As this was a straight-up MUST NOT, it seems prudent to renumber. And if we're renumbering anyway, may as well avoid all the old SignatureAlgorithms and avoid confusing tools like Wireshark.

Discussion:
TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC2434.  Values with the first byte 255 (decimal) are reserved <del> for Private Use RFC2434.  This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated with the values described in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. [[TODO: How to denote that values ending in 0x00 through 0x03 are also reserved?]] </del> <ins> for Private Use RFC2434.  Values with the first byte in the range 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. This registry SHALL have a "Recommended" column.  The registry [shall be/ has been] initially populated with the values described in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. </ins> Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in
Change:
By the way, you also need to update Version Negotiation section of the .
lgtm
Done , Xiaoyin Liu EMAIL wrote:

Discussion:
server's selected version is contained in the ServerHello.version field as in previous versions of TLS. <ins> 4.2.1.1. RFC EDITOR: PLEASE REMOVE THIS SECTION While the eventual version indicator for the RFC version of TLS 1.3 will be {3, 4}, implementations of draft versions of this specification SHOULD instead advertise {0x7f, [draft-version]} in their "supported_versions" extension, in ServerHello.version, and HelloRetryRequest.server_version.  This allows pre-RFC implementations to safely negotiate with each other, even if they would otherwise be incompatible. </ins> 4.2.2. %%% Cookie Extension
Change:
ClientHello.version -> ClientHello.legacy_version
Merged. Please send me a PR adding yourself to Contributors in alphabetical order
NAME Thank you! Done in PR .

Discussion:
preferences and MUST only select a version of TLS present in that extension.  They MUST ignore any unknown versions.  If the extension is not present, they MUST negotiate TLS 1.2 or prior as specified in <del> RFC5246, even if ClientHello.version is {3, 4} or later. </del> <ins> RFC5246, even if ClientHello.legacy_version is {3, 4} or later. </ins> The server MUST NOT send the "supported_versions" extension.  The server's selected version is contained in the ServerHello.version
Change:
In the first paragraph, remove "that selects cryptographic parameters that don’t match the client’s 'keyshare' extension". Reason: According to section 4.2.5, HelloRetryRequest might not include the “keyshare” extension. Also there is a whole section for Hello Retry Request. So I don't think we need to explain what a HelloRetryRequest is here.

Discussion:
When a client first connects to a server, it is REQUIRED to send the ClientHello as its first message.  The client will also send a ClientHello when the server has responded to its ClientHello with <del> a HelloRetryRequest that selects cryptographic parameters that don't match the client's "key_share" extension.  In that case, the client MUST send the same ClientHello (without modification) except: </del> <ins> a HelloRetryRequest.  In that case, the client MUST send the same ClientHello (without modification) except: </ins> Including a new KeyShareEntry as the lowest priority share (i.e., appended to the list of shares in the "key_share" extension).
Change:
PR changed enum values which would need updating by any experimental implementations that were actually using them. Even if this doesn't come up in practice, it should be listed in the changelog.

Discussion:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-16 Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better backwards compatibility (*) </ins> draft-15 New negotiation syntax as discussed in Berlin (*)
Change:
Criteria for one member structure / non structure is as follows: Non structure: basic type -- not messages nor extensions One member structure: others such as messages or extensions
LGTM

Discussion:
by sending the client an empty "signature_algorithms" extension. The "extension_data" field of this extension in a ClientHello <del> contains a "supported_signature_algorithms" value: </del> <ins> contains a SignatureSchemeList value: </ins> %%% Signature Algorithm Extension

rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list <del> them as the lowest priority (listed after all other algorithms in the supported_signature_algorithms vector).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </del> <ins> them as the lowest priority (listed after all other algorithms in SignatureSchemeList).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). </ins> The signatures on certificates that are self-signed or certificates that are trust anchors are not validated since they begin a
Change:
I am proposing that a client can also use the Zero-RTT with PSK-based authentication without having to rely on a previously obtained ticket.
Surely there would need to be additional security considerations for this behavior?!
This seems reasonable and was my intent, at least. Can you fix the build problem.
Could you please add linebreaks to wrap to about 80 character or so lines? Our line length is often rather inconsistent, but we do generally try to keep lines shorter than in the current changeset.
This LGTM. I'll let it sit for a little but in case anyone wants to weigh in (NAME NAME NAME
That's the sort of additional considerations that I was expecting to see, yes. I think that you got the list basically right, though there are a few things here that could be clearer.

Discussion:
2.3. <del> When resuming via a PSK with an appropriate ticket (i.e., one with the "early_data_info" extension), clients can also send data on their first flight ("early data").  This data is encrypted solely under keys derived using the first offered PSK as the static secret.  As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </del> <ins> With the Zero-RTT mode clients can send data on their first flight ("early data") whereby the client uses a PSK either obtained out-of- band or as a ticket (i.e., one with the "early_data_info" extension) from an earlier exchange to authenticate to the server. When clients use a PSK obtained out-of-band then the following information MUST be provisioned to both parties: * PSK identity, * ciphersuite for use with this PSK, * key exchange and authentication modes this PSK is allowed to be used with, * the Application-Layer Protocol Negotiation (ALPN) label(s), and * optionally the Server Name Indication (SNI). As shown in tls-0-rtt, the Zero-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.

IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data.  Specifically: <del> This data is not forward secret, because it is encrypted solely with the PSK. </del> <ins> The early data is encrypted solely under keys derived using the offered PSK as the static secret.  Hence, this data is not forward secret, because it is encrypted solely with the PSK. </ins> There are no guarantees of non-replay between connections.  Unless the server takes special measures outside those provided by TLS,
Change:
I wanted to clarify in what part of the exchange the certificaterequestcontext field has a zero length.

Discussion:
which will be echoed in the client's Certificate message.  The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client <del> CertificateVerify messages).  Within the handshake, this field MUST be empty. </del> <ins> CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges described in Section 4.5.2. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any
Change:
Various changes to make exporters/resumption work better. The rationale is to be able to do stuff in 0/0.5RTT. Add a 0-RTT exporter and change the transcript for the regular exporter (*). Explicitly allow predicting ClientFinished for NST when not doing Client auth.

Discussion:
is provided, the value is computed as: Where Secret is either the early_exporter_secret or the <del> exporter_secret. </del> <ins> exporter_secret.  Implementations MUST use the exporter_secret unless 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. </ins> If no context is provided, the value is computed as:
Change:
The MTI Extensions section is currently out-of-date. It wasn't updated with the new negotiation and still refers to the old cipher suites system. This PR cleans that up. I also drop the cookie extension universal send requirement, as that was in there as an alternative to allowing a server to send a cookie without first being prompted. We have that in as an explicit exception, currently.
I already did some of this in PR, so I'm going to hold this PR until that has landed and then we can take stock
Sure, I hadn't read that PR yet. A notable difference in the language here is that I'm replacing the "MAY abort the connection" line with specific requirements, as that high level of generalization is counterproductive now that cipher suites and feature extensions are decoupled.

Discussion:
Pre-Shared Key ("pre_shared_key"; pre-shared-key-extension) <del> Server Name Indication ("server_name"; Section 3 of RFC6066) </del> Cookie ("cookie"; cookie) <ins> Server Name Indication ("server_name"; Section 3 of RFC6066) </ins> All implementations MUST send and use these extensions when offering <del> applicable cipher suites: </del> <ins> applicable features: </ins> "supported_versions" is REQUIRED for all ClientHello messages. <del> "signature_algorithms" is REQUIRED for certificate authenticated cipher suites. </del> <ins> "signature_algorithms" is REQUIRED for certificate authentication. </ins> "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE <del> cipher suites. </del> <ins> key exchange. </ins> <del> "pre_shared_key" is REQUIRED for PSK cipher suites. </del> <ins> "pre_shared_key" is REQUIRED for PSK key agreement. </ins> <del> "cookie" is REQUIRED for all cipher suites. </del> <ins> A client is considered to be attempting to negotiate using this specification if the ClientHello contains a "supported_versions" extension, at minimum.  Such ClientHello messages MUST meet following requirements: </ins> <del> When negotiating use of applicable cipher suites, endpoints MUST abort the handshake with a "missing_extension" alert if the required extension was not provided.  Any endpoint that receives an invalid combination of cipher suites and extensions MAY abort the connection with a "missing_extension" alert, regardless of negotiated parameters. </del> <ins> If not containing a "pre_shared_key" extension, it MUST contain both a "signature_algorithms" extension and a "supported_groups" extension. If containing a "supported_groups" extension, it MUST also contain a "key_share" extension, and vice versa. (an empty KeyShare.client_shares vector is permitted) Servers receiving a ClientHello which is attempting to negotiate using this specification, yet failing any of the above requirements, MUST abort the handshake with a "missing_extension" alert. </ins> Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it.
Change:
To let's add some explanations to Section 3.
I have written a syntax validator to check the validity of definitions. In this issue, I would like to point out what I noticed.
(1) Some enum definitions use "floor..ceiling" notation which is not defined. Section 3.5 should clearly define this.
(2) I think that the keyword is allowed only in the top level definitions. But is used inside of EarlyDataIndication. I would suggest to defined the following in the top level:
(3) The following assignment is really strange: I would suggest to change this to:
On Wednesday, September 07, 2016 04:24:15 am Kazu Yamamoto wrote: I don't understand why you consider this current notation here strange. It's the same notation used for enum values elsewhere.
What I can tell from Section 3 is as follows: The "symbol(num)" notation is allowed in the declaration of enum. "symbol" can be used as label of the case clause. "{num, ...}" can be used for assignment. I don't see that "symbol(num)" can be used for assignment. I wrote a parse based on Section 3 and what I reported here is the errors reported by the parser.

Discussion:
T.f2 refers to the second field of the previous declaration. Structure definitions may be embedded. <ins> Basically the "struct" notation is used in the top level to define a new type.  However, there is one exception that an anonymous structure "struct {}", which means empty, can be used inside of another structure. </ins> 3.6.1. Defined structures may have variants based on some knowledge that is
Change:
with few possible exceptions, enumerateds will assume values different than the ones they were originally defined with. Backwards compatibility of Client Hello is dependent on implementations being able to ignore values they do not know about.
This doesn't seem quite right. Some enums are complete in the sense that you should not ignore unknown ones (HandshakeType) and some are not complete (ExtensionType, CipherSuite).
How about then "URL parse and ignore them unless the their deifnition states otherwise".?
sure that would be fine

Discussion:
3.5. <del> An additional sparse data type is available called enum.  A field of type enum can only assume the values declared in the definition. Each definition is a different type.  Only enumerateds of the same type may be assigned or compared.  Every element of an enumerated must be assigned a value, as demonstrated in the following example. Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. </del> <ins> An additional sparse data type is available called enum.  Each definition is a different type.  Only enumerateds of the same type may be assigned or compared.  Every element of an enumerated must be assigned a value, as demonstrated in the following example.  Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. Future extension or additions to the protocol may define new values. Implementations need to be able to parse and ignore them unless their definition states otherwise. </ins> An enumerated occupies as much space in the byte stream as would its maximal defined ordinal value.  The following definition would cause

force the width definition without defining a superfluous element. In the following example, Taste will consume two bytes in the data <del> stream but can only assume the values 1, 2, or 4. </del> <ins> stream but can only assume the values 1, 2, or 4 in current version of protocol. </ins> The names of the elements of an enumeration are scoped within the defined type.  In the first example, a fully qualified reference to
Change:
Before record protection is established, if an endpoint receives a TLSPlaintext structure whose "length" field is too large (>2^14), should it send a "record_overflow" alert?

Discussion:
deprecated and MUST be ignored for all purposes. The length (in bytes) of the following TLSPlaintext.fragment.  The <del> length MUST NOT exceed 2^14. </del> <ins> length MUST NOT exceed 2^14.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </ins> The data being transmitted.  This value transparent and treated as an independent block to be dealt with by the higher-level protocol
Change:
All other fields deprecated by this spec use "MUST be set to ...", such as ClientHello.legacyversion, ClientHello.legacycompressionmethods, TLSPlaintext.legacyrecordversion. Only ClientHello.legacysession_id "SHOULD be set as [...]" So I suggest changing this to "MUST" as well.

Discussion:
Versions of TLS before TLS 1.3 supported a session resumption feature which has been merged with Pre-Shared Keys in this version (see resumption-and-psk).  This field MUST be ignored by a server <del> negotiating TLS 1.3 and SHOULD be set as a zero length vector (i.e., a single zero byte length field) by clients which do not have a cached session ID set by a pre-TLS 1.3 server. </del> <ins> negotiating TLS 1.3 and MUST be set as a zero length vector (i.e., a single zero byte length field) by clients which do not have a cached session ID set by a pre-TLS 1.3 server. </ins> This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including
Change:
RFC 5226 obsoleted RFC 2434 so we should refer to that to avoid a GENART review comment.

Discussion:
registries and their allocation policies are below: TLS Cipher Suite Registry: Values with the first byte in the range <del> 0-254 (decimal) are assigned via Specification Required RFC2434. </del> <ins> 0-254 (decimal) are assigned via Specification Required RFC5226. </ins> Values with the first byte 255 (decimal) are reserved for Private <del> Use RFC2434. </del> <ins> Use RFC5226. </ins> IANA [SHALL add/has added] the cipher suites listed in cipher- suites to the registry.  The "Value" and "Description" columns are

D.sandj-tls-iana-registry-updates has been applied.]] TLS ContentType Registry: Future values are allocated via <del> Standards Action RFC2434. </del> <ins> Standards Action RFC5226. </ins> TLS Alert Registry: Future values are allocated via Standards <del> Action RFC2434. </del> <ins> Action RFC5226. </ins> TLS HandshakeType Registry: Future values are allocated via <del> Standards Action RFC2434.  IANA [SHALL update/has updated] this </del> <ins> Standards Action RFC5226.  IANA [SHALL update/has updated] this </ins> registry to rename item 4 from "NewSessionTicket" to "new_session_ticket".

TLS ExtensionType Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required <del> RFC2434.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434.  IANA [SHALL update/has updated] this </del> <ins> RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226.  IANA [SHALL update/has updated] this </ins> registry to include the "key_share", "pre_shared_key", and "early_data" extensions as defined in this document.

TLS SignatureScheme Registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required <del> RFC2434.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434.  Values with the first byte in the range </del> <ins> RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226.  Values with the first byte in the range </ins> 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility. This registry SHALL have a "Recommended" column.  The registry
Change:
The caveats at the beginning are silly We don't seem to every use Foo = { A, B} but we do use Foo = A;
Fixed, thanks

Discussion:
This document deals with the formatting of data in an external representation.  The following very basic and somewhat casually <del> defined presentation syntax will be used.  The syntax draws from several sources in its structure.  Although it resembles the programming language "C" in its syntax and XDR RFC4506 in both its syntax and intent, it would be risky to draw too many parallels.  The purpose of this presentation language is to document TLS only; it has no general application beyond that particular goal. </del> <ins> defined presentation syntax will be used. </ins> 3.1.

Structure definitions may be embedded.  Anonymous structs may also be defined inside other structures. <del> 3.6.1. </del> <ins> 3.7. Fields and variables may be assigned a fixed value using "=", as in: 3.7.1. </ins> Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated

For example: <del> 3.7. Typed constants can be defined for purposes of specification by declaring a symbol of the desired type and assigning values to it. Under-specified types (opaque, variable-length vectors, and structures that contain opaque) cannot be assigned values.  No fields of a multi-element structure or vector may be omitted. For example: </del> 3.8. TLS defines two generic alerts (see alert-protocol) to use upon
Change:
I believe that these are just cleanup, though you might want to check the PSK one a little more carefully (happy to separate it if it is a problem).
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:
server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an <del> extension in the CertificateEntry containing the assoiciated </del> <ins> extension in the CertificateEntry containing the associated </ins> certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961
Change:
We don't actually use this syntax, and having it in here just adds useless complexity. Defining syntax we don't actually use just risks confusing people reading the document for the first time.

Discussion:
qualification is not required if the target of the assignment is well specified. <del> For enumerateds that are never converted to external representation, the numerical information may be omitted. </del> The names assigned to enumerateds do not need to be unique.  The numerical value can describe a range over which the same name applies.  The value includes the minimum and maximum inclusive values
Change:
This extension is now empty. Minor cleanup.
I think "it's own" is useful, but my instinct is that having the empty struct makes life easier.
If you would rather keep the empty struct, I don't have a strong objection. Repushed with just the minor wording tweak.

Discussion:
the server has ignored any early data and an ordinary 1-RTT handshake is required. <del> Return an empty extension, indicating that it intends to process </del> <ins> Return its own extension, indicating that it intends to process </ins> the early data.  It is not possible for the server to accept only a subset of the early data messages.