jiebi/CodeConvo huggingface dataset:
Change:
Consistently capitalize AEAD, fix a missing period, and fix a typo in a comment (for the sole purpose of appeasing my perfectionist tendencies ;).
I don't think changing aead-ciphered to AEAD-ciphered in the protocol description is an improvement. The typo fix is good :)
3 lines below aead-ciphered we have TLSCiphertext. Abbreviations are already kept in caps in almost every place. I don't see why it shouldn't be consistent and do so here as well.
I'd prefer to stay consistent with TLS 1.2.
Meh, ok. It looks out of place to me, but it's not a big deal. Commit revised to just fix the missing period and typo.

Discussion:
the certificate for future handshakes based on the CertificateRequest parameters supplied in this handshake.  The server MUST NOT send either of these two options unless it also <del> requested a certificate on this handshake [[OPEN ISSUE: Shoudl we relax this?]] </del> <ins> requested a certificate on this handshake.  [[OPEN ISSUE: Should we relax this?]] </ins> This field is a placeholder for future extensions to the
Change:
Missing semi-colon in the message definition. Also, the signature_algorithms of the client are what matter.

Discussion:
Structure of this message: %%% Authentication Messages struct { digitally-signed struct { opaque <del> handshake_hash[hash_length]; } } CertificateVerify; </del> <ins> handshake_hash[hash_length]; }; } CertificateVerify; </ins> Where session_hash is as described in the-handshake-hash and includes the messages sent or received, starting at ClientHello

for CertificateVerify, Finished and other messages. The signature algorithm and hash algorithm MUST be a pair offered <del> in the "signature_algorithms" extension (see signature- </del> <ins> in the client's "signature_algorithms" extension (see signature- </ins> algorithms).  Note that there is a possibility for inconsistencies here.  For instance, the client might offer DHE_DSS key exchange but omit any DSA pairs from its "signature_algorithms" extension.
Change:
Provide a temporary URL in the draft for people wanting to submit pull requests, so that they don't have to search the archives for Sean's message from April 17.
We should probably wrap long lines that reviewing is a little easier. The rest of the doc wraps at 80.

Discussion:
1.2 remain in this version.  Thanks to Mark Nottingham for doing the markdown translation. <ins> [RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH] The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/tlswg/tls13-spec . Instructions are on that page as well.  Editorial changes can be managed in GitHub, but any substantive change should be discussed on the TLS mailing list. </ins> The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.  The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake
Change:
This completes the removal of SHA-1 for CertificateVerify. There's no reason to allow it there at all
LGTM

Discussion:
All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional <del> hashing.  The default hash function is SHA-1 SHS.  However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-4 SHS SHOULD be used instead if the certificate containing the EC public key explicitly requires use of another hash function.  (The mechanism for specifying the required hash function has not been standardized, but this provision anticipates such standardization and obviates the need to update this document in response.  Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)  [[OPEN ISSUE: This needs updating per 4492-bis https://github.com/tlswg/tls13-spec/issues/59]]. </del> <ins> hashing.  The SignatureAndHashAlgorithm parameter in the DigitallySigned object indicates the digest algorithm which was used in the signature. </ins> In the following example

be used with any permitted hash algorithm, subject to restrictions in the certificate, if any.  RSA signatures MUST be based on RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in <ins> "signature_algorithms".  SHA-1 MUST NOT be used in any signatures in CertificateVerify, regardless of whether SHA-1 appears in </ins> "signature_algorithms". 6.3.9.

permitted hash algorithm, subject to restrictions in the certificate, if any.  RSA signatures MUST be based on RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in <ins> "signature_algorithms".  SHA-1 MUST NOT be used in any signatures in CertificateVerify, regardless of whether SHA-1 appears in </ins> "signature_algorithms". 6.3.12.
Change:
This is stated to exist in the definition for "signature", however the value wasn't actually added to the enum. ( URL )

Discussion:
sha1_RESERVED(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; <ins> [[TODO: IANA considerations for new SignatureAlgorithm value]] </ins> Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated in descending order of preference.
Change:
NAME please confirm this matches consensus
Now that we are removing static RSA cipher suites, we need a new MTI cipher suite.
From Sean's mail o Symmetric: MUST AES-GCM 128 [SHOULD ChaCha20-Poly1305] o Hash: MUST SHA-256 o Key Agreement: ECDH MUST P-256 [SHOULD 25519] o Signature: MUST ECDSA P-256 MUST RSA
Dear Mr. NAME currently I'm very interested in studying non-repudiation, then I found S-HTTP (RFC 2660) that offer non-repudiation security service. I also found that AS2 (RFC 4130) also offers this kind of service, but then I wonder why non-repudiation service is not becoming ubiquotus? Why AEAD replace HMAC, does hash function is too heavy, or hash is more appropriate for digital signature world? Thanks

Discussion:
Deprecate SHA-1 with signatures. <ins> Add MTI algorithms. </ins> draft-08 Remove support for weak and lesser used named curves.

preference. Clients may offer an arbitrary number of ClientKeyShareOffer values, <del> each representing a single set of key agreement parameters; for </del> <ins> each representing a single set of key exchange parameters; for </ins> instance a client might offer shares for several elliptic curves or multiple integer DH groups.  The shares for each ClientKeyShareOffer MUST by generated independently.  Clients MUST NOT offer multiple

In order to begin connection protection, the TLS Record Protocol requires specification of a suite of algorithms, a master secret, and the client and server random values.  The authentication, key <del> agreement, and record protection algorithms are determined by the </del> <ins> exchange, and record protection algorithms are determined by the </ins> cipher_suite selected by the server and revealed in the ServerHello message.  The random values are exchanged in the hello messages.  All that remains is to calculate the key schedule.

8.1. In the absence of an application profile standard specifying <del> otherwise, a TLS-compliant application MUST implement the cipher suite TODO:Needs to be selected [1].  (See cipher-suites for the definition.) </del> <ins> otherwise, a TLS-compliant application MUST implement the following cipher suites: These cipher suites MUST support both digital signatures and key exchange with secp256r1 (NIST P-256) and SHOULD support key agrement with X25519 I-D.irtf-cfrg-curves. A TLS-compliant application SHOULD implement the following cipher suites: </ins> 8.2.

(decimal) inclusive are assigned via Specification Required RFC2434.  Values from 224-255 (decimal) inclusive are reserved for Private Use RFC2434. <del> 12.  References 12.1.  URIs [1] https://github.com/tlswg/tls13-spec/issues/32 </del>
Change:
…che).
Aside from the little nits and typo, the text itself looks good to me.

Discussion:
The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document <del> except DH_anon and PSK).  This message will always immediately follow the EncryptedExtensions message. </del> <ins> except PSK).  This message will always immediately follow the EncryptedExtensions message. </ins> Meaning of this message:
Change:
LGTM
This was always a hack. We should just remove mention of this as a "cipher suite" and just talk about certain messages being encrypted and others not.
If issue is done, then I think the only cleartext messages left would be the 3 hello messages: ClientHello, ServerHello, & HelloRetryRequest. TLSPlaintext could then just be renamed to TLSHelloRecord, which would make the distinction between cleartext and encrypted records relatively easy.
I agree that this psuedo-cipher-suite should be removed. It is confusing. Some implementations may work in a way where they implement some TLSNULLNULLWITHNULL_... cipher suite, but that's an implementation detail. Other implementations, particularly implementations that don't do renegotiation, likely won't work like that.

Discussion:
fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. <ins> When record protection has not yet been engaged, TLSPlaintext structures are written directly onto the wire.  Once record protection has started, TLSPlaintext records are protected and sent as described in the following section. </ins> 5.2.2. The record protection functions translate a TLSPlaintext structure

maximum TLSPlaintext length of 2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets. <del> TODO: explain how TLS_NULL_WITH_NULL_NULL is not actually a cipher at all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext </del> 5.2.3. All encrypted TLS records can be padded to inflate the size of the
Change:
There are a couple of times the reserved values don't include the string "RESERVED". Can we either note this in the intro or add "RESERVED" to the appropriate places in ContentType and HandshakeType:
If we can remove all the fields suffixed by it would make the enums more easy to read. =)

Discussion:
TLSPlaintext or TLSCiphertext structures, which are processed and transmitted as specified by the current active session state. <del> %%% Handshake Protocol enum { reserved(0), client_hello(1), server_hello(2), session_ticket(4), hello_retry_request(6), server_key_share(7), encrypted_extensions(8), certificate(11), reserved(12), certificate_request(13), reserved(14), certificate_verify(15), reserved(16), server_configuration(17), finished(20), (255) } HandshakeType; </del> <ins> %%% Handshake Protocol enum { hello_request_RESERVED(0), client_hello(1), server_hello(2), session_ticket(4), hello_retry_request(6), server_key_share(7), encrypted_extensions(8), certificate(11), server_key_exchange_RESERVED(12), certificate_request(13), server_hello_done_RESERVED(14), certificate_verify(15), client_key_exchange_RESERVED(16), server_configuration(17), finished(20), (255) } HandshakeType; </ins> The TLS Handshake Protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order
Change:
Chairs have judged that there is consensus to merge, see: URL It looks like we have rough consensus to accept this PR. We should make sure we note the limitations that Karthink brought up for PSK and RSA, URL Procedurally, we should document the requirements for TLS 1.2 in a separate draft to update TLS 1.2 in parallel. This may be necessary to get us out of the situation where we have to update and obsolete a specification at the same time. Thanks, J&S , Eric Rescorla wrote:

Discussion:
TLS 1.3 server implementations which respond to a ClientHello with a client_version indicating TLS 1.2 or below MUST set the first eight <del> bytes of its Random value to the bytes 44 4F 57 4E 47 52 44 01.  TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check that the top eight octets are not equal to either this value or 44 4F 57 4E 47 52 44 00 (which SHOULD by used by TLS 1.2 servers which are negotiating TLS 1.1 or below).  If a match is found the client MUST </del> <ins> bytes of their Random value to the bytes: TLS 1.2 server implementations which respond to a ClientHello with a client_version indicating TLS 1.1 or below SHOULD set the first eight bytes of their Random value to the bytes: TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check that the top eight octets are not equal to either of these values. TLS 1.2 clients SHOULD also perform this check if the ServerHello indicates TLS 1.1 or below.  If a match is found the client MUST </ins> abort the handshake with a fatal "illegal_parameter" alert.  This mechanism provides limited protection against downgrade attacks over and above that provided by the Finished exchange: because the

detection as long as ephemeral ciphers are used.  It does not provide downgrade protection when static RSA is used. <ins> Note: This is an update to TLS 1.2 so in practice many TLS 1.2 clients and servers will not behave as specified above. </ins> Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the Random value to encode the time since the UNIX epoch.  The sentinel value above was selected to avoid conflicting with any valid TLS 1.2
Change:
The struct contains a value named handshakehash, not sessionhash. I apparently had fixed this in PR . Pulling it out separately to get it in now, as it hasn't even been decided for sure if we're doing that.

Discussion:
%%% Authentication Messages struct { digitally-signed struct { opaque handshake_hash[hash_length]; }; } CertificateVerify; <del> Where session_hash is as described in the-handshake-hash and </del> <ins> Where handshake_hash is as described in the-handshake-hash and </ins> includes the messages sent or received, starting at ClientHello and up to, but not including, this message, including the type and length fields of the handshake messages.  This is a digest of the
Change:
I think sha1 is supposed to be removed from this? If not, the int is missing sha2. enum { none(0), sha1, sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm;
No, it's there because you can offer it for certs. It is missing the assignment. PRs welcome :)
Okay so it's just missing the "(2)". I'll get on the PR.
Fixed by PR

Discussion:
"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), <del> sha1, sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } </del> <ins> sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } </ins> HashAlgorithm; [[TODO: IANA considerations for new SignatureAlgorithm value]]
Change:
The RSA-PSS salt length seems to be missing from the specification. The original post on the mailing list and a few other sources propose that where is the length of the digest output in bytes. Should this be raised on the mailing list again or was this agreed on already?
Let's just do it the way you propose. PR welcome

Discussion:
using the RSASSA-PSS signature scheme defined in RFC3447 with MGF1. The digest used in the mask generation function MUST be the same as the digest which is being signed (i.e., what appears in <del> algorithm.signature).  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </del> <ins> algorithm.signature).  The length of the salt MUST be equal to the octet length of the digest output.  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the
Change:
Fix spacing to match other flow charts & fix one KeyShare->KeyShareEntry that was missed.

Discussion:
A single KeyShareEntry value for the negotiated cipher suite. <del> Servers MUST NOT send a KeyShare for a group not offered by the client. </del> <ins> Servers MUST NOT send a KeyShareEntry value for a group not offered by the client. </ins> Servers offer exactly one KeyShareEntry value, which corresponds to the key exchange used for the negotiated cipher suite.
Change:
Starts in this thread: URL spt
It's the nonce after all. On Monday, October 19, 2015, Martin Thomson wrote: I don't believe that there's any reason to include the sequence number in the AD input of an AEAD. I think that an empty AD for TLS would be fine now that the content type is encrypted. (Not that I deeply care either way.) Cheers AGL Adam Langley EMAIL URL

Discussion:
Merge client and server key shares into a single extension. <ins> Remove sequence number and version from additional_data, which is now empty. </ins> draft-09 Change to RSA-PSS signatures for handshake messages.
Change:
This addresses Brian's comment from . We don't use "octet length" anywhere else in the document.

Discussion:
The digest used in the mask generation function MUST be the same as the digest which is being signed (i.e., what appears in algorithm.signature).  The length of the salt MUST be equal to the <del> octet length of the digest output.  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </del> <ins> length of the digest output.  Note that previous versions of TLS used RSASSA-PKCS1-v1_5, not RSASSA-PSS. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the
Change:
The spec always uses the gender-neutral possessive pronoun "its" for "client", so I think we should definitely fix that occurrence. Also, it seems that throughout the document we try to not use gender-specific pronouns for "attacker". I'm not sure about "their" though, as it looks like we usually try to avoid that by restructuring sentences, but I may be mistaken. We could also refer to multiple attackers?
In technical writing, we should generally use "they" and "their" everywhere when (potentially) referring to a person or persons. ("it" is best for denoting clients/servers) The word "they" gives both gender & quantity neutral language; no assumptions. (this use is older than Shakespeare; it's just underused)

Discussion:
zero-rtt-exchange) it also authenticates the handshake using the the Static Secret. [server-finished] <del> Upon receiving the server's messages, the client responds with his </del> <ins> Upon receiving the server's messages, the client responds with its </ins> final flight of messages:
Change:
The early_data extension should be listed as one of the few that can't go into EncryptedExtensions but must be sent with ServerHello.

Discussion:
between the ServerHello and the EncryptedExtensions encrypted- extensions message.  The ServerHello MUST only include extensions which are required to establish the cryptographic context. <del> Currently the only such extensions are "key_share" and "pre_shared_key".  Clients MUST check the ServerHello for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </del> <ins> Currently the only such extensions are "key_share", "pre_shared_key", and "early_data".  Clients MUST check the ServerHello for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </ins> 6.3.1.3.
Change:
The current text is a mix of omitting and sending empty, as pointed out by Ilari on the mailing list. This fixes things and switches to an always-send model.
This looks good to me modulo the issue noted above
NAME Ok, I've pushed a second commit here which clarifies that point and also reconciles the fact that the two extensions here both claim to determine group priority. Suggestions to reduce verbosity without reducing clarity would be appreciated. (this commit fixes issue )
Typo fixed & rebased.
Since the list is in favor of "forward secrecy" over "forward security", I've changed my use of the term in this PR to the former (a commit just landed to change the existing uses elsewhere). Not rebased again; still merges cleanly (for the moment, at least).

Discussion:
MUST NOT offer any KeyShareEntry values for groups not listed in the client's "supported_groups" extension.  Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its <del> corresponding KeyShare. </del> <ins> corresponding KeyShare.  Implementations receiving any KeyShare containing any of these prohibited values MUST abort the connection with a fatal "illegal_parameter" alert. </ins> If no mutually supported group is available between the two endpoints' KeyShare offers, yet there is a mutually supported group
Change:
When talking about handling downlevel clients, the spec variously says a server "MAY" receive such messages, or "may" receive such messages. Since this is discussing a possibility (not a permitted behavior), the normative language isn't correct; lower-case versions of the RFC2119 terms have the potential to confuse readers. Suggest changing all of these to "might" to denote a possible occurrence server implementers will need to handle.
Yes, this looks like an improvement.
LGTM

Discussion:
zero, which corresponds to the "null" compression method in prior versions of TLS.  If a TLS 1.3 ClientHello is received with any other value in this field, the server MUST generate a fatal <del> "illegal_parameter" alert.  Note that TLS 1.3 servers may receive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS. </del> <ins> "illegal_parameter" alert.  Note that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which contain other compression methods and MUST follow the procedures for the appropriate prior version of TLS. </ins> Clients MAY request extended functionality from servers by sending

that is not advertised as being supported in the signature_algorithms extension. <del> Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not </del> <ins> Note: TLS 1.3 servers might receive TLS 1.2 ClientHellos which do not </ins> contain this extension.  If those servers are willing to negotiate TLS 1.2, they MUST behave in accordance with the requirements of RFC5246 when negotiating that version.
Change:
This section has a strange table that looked a little messy. So I cleaned that up. However, I noticed that it used to say this: Which doesn't make any sense. Should this be signature_algorithms extension instead?

Discussion:
The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the key usage extension is present) with the signature scheme and hash algorithm that will be <del> employed in the server's KeyShare extension. </del> <ins> employed in the server's signature_algorithms extension. </ins> An ECDSA or EdDSA public key MUST use a curve and point format supported by the client, as described in RFC4492.