jiebi/CodeConvo huggingface dataset:
Code change:
This change clarifies that the signature over ServerDHParams data is a signature over the hash of the client + server hello random random data and the ServerDHParams data. I believe this small regression was introduced in TLS1.2 with the result that the TLS1.2 RFC (and current TLS1.3 draft) does not contain sufficient detail to implement TLS + DHE. All TLS1.2 clients and servers that I have tested do include the hello random data (and omitting it would leave implementations open to replay attacks).
Thanks for the PR. Note that the formal PDU definitions here appear to be correct, so there should be enough information to implement things correctly: I agree it wouldn't hurt to have the explanatory text be clearer. However, in TLS 1.2 we stopped explicitly saying that things were hashed before signing (because we are treating signing as a primitive), so we probably don't want to say "hash". Maybe just say a signature over the random values and the params?
Ah, this explains my confusion. After reading section 7.4.1.4.1, I formed the opposite impression about signing; that hashing and signing are explicitly different primitive operations and may be composed in a variety of ways. But I see how that "digitally-signed" seems to be a reserved term that implies both operations.
I'm not trying to discourage you here. If you were confused, others will probably be as well, so if you have some text that you think would clear this up, it would be welcome.
Thanks! I've updated the PR with an even simpler diff that I think would have made me less confused when I got to it.

Related discussion:
text: The server's key exchange parameters. <del> For non-anonymous key exchanges, a signature over the server's key exchange parameters. </del> <ins> For non-anonymous key exchanges, a signature over the client and server hello random data and the server's key exchange parameters. </ins> If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that
Code change:
Lack of a blank line after "draft-14" but before the bullet point causes it to render all on one line: URL This is just a quick patch to make the spacing consistent because apparently Markdown (or, at least whatever is interpreting it there) can be picky. ;) This is just a whitespace fix.

Related discussion:
text: 1.2. <del> draft-14 - Allow cookies to be longer. </del> <ins> draft-14 Allow cookies to be longer. </ins> draft-13
Code change:
NAME NAME PTAL
LGTM
lgtm
Don't forget no_certificate.
Not relevant: nocertificateRESERVED(41), / fatal / , Martin Thomson EMAIL wrote:
Right. I just noticed that we send an empty certificate instead.

Related discussion:
text: 6. One of the content types supported by the TLS record layer is the <del> alert type.  Alert messages convey the severity of the message (warning or fatal) and a description of the alert.  Alert messages with a level of fatal result in the immediate termination of the connection.  Like other messages, alert messages are encrypted as </del> <ins> alert type.  Like other messages, alert messages are encrypted as </ins> specified by the current connection state. <ins> Alert messages convey the severity of the message (warning or fatal) and a description of the alert.  Warning-level messages are used to indicate orderly closure of the connection (see closure-alerts). Upon receiving a warning-level alert, the TLS implementation SHOULD indicate end-of-data to the application and, if appropriate for the alert type, send a closure alert in response. Fatal-level messages are used to indicate abortive closure of the connection (See error-alerts).  Upon receiving a fatal-level alert, the TLS implementation SHOULD indicate an error to the application and MUST NOT allow any further data to be sent or received on the connection.  Servers and clients MUST forget keys and secrets associated with a failed connection.  Stateful implementations of session tickets (as in many clients) SHOULD discard tickets associated with failed connections. All the alerts listed in error-alerts MUST be sent as fatal and MUST be treated as fatal regardless of the AlertLevel in the message. Unknown alert types MUST be treated as fatal. </ins> %%% Alert Messages 6.1.
Code change:
NAME NAME PTAL
LGTM
lgtm
Don't forget no_certificate.
Not relevant: nocertificateRESERVED(41), / fatal / , Martin Thomson EMAIL wrote:
Right. I just noticed that we send an empty certificate instead.

Related discussion:
text: 6.2. <del> Error handling in TLS is very simple.  When an error is detected, the detecting party sends a message to its peer.  Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.  Servers and clients MUST forget keys, and secrets associated with a failed connection.  Stateful implementations of session tickets (as in many clients) SHOULD discard tickets associated with failed connections. Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing the connection.  For all errors where an alert level is not explicitly specified, the sending party MAY determine at its discretion whether to treat this as a fatal error or not.  If the implementation chooses to send an alert but intends to close the connection immediately afterwards, it MUST send that alert at the fatal alert level. If an alert with a level of warning is sent and received, generally the connection can continue normally.  If the receiving party decides not to proceed with the connection (e.g., after having received a "user_canceled" alert that it is not willing to accept), it SHOULD send a fatal alert to terminate the connection.  Given this, the sending peer cannot, in general, know how the receiving party will behave.  Therefore, warning alerts are not very useful when the sending party wants to continue the connection, and thus are sometimes omitted.  For example, if a party decides to accept an expired certificate (perhaps after confirming this with the user) and wants to continue the connection, it would not generally send a "certificate_expired" alert. </del> <ins> Error handling in the TLS Handshake Protocol is very simple.  When an error is detected, the detecting party sends a message to its peer. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.  Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing the connection. </ins> The following error alerts are defined:
Code change:
As all error alerts are now considered fatal (PR ), we no longer need "This alert is always fatal" explicitly stated everywhere in that section.

Related discussion:
text: Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.  Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST <del> send the appropriate alert prior to closing the connection. </del> <ins> send the appropriate alert prior to closing the connection.  All alerts defined in this section below, as well as all unknown alerts are universally considered fatal as of TLS 1.3 (see alert-protocol). </ins> The following error alerts are defined: <del> An inappropriate message was received.  This alert is always fatal and should never be observed in communication between proper implementations. </del> <ins> An inappropriate message was received.  This alert should never be observed in communication between proper implementations. </ins> This alert is returned if a record is received which cannot be deprotected.  Because AEAD algorithms combine decryption and verification, this alert is used for all deprotection failures. <del> This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record <del> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> with more than 2^14 bytes.  This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> 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 alert is always fatal. </del> <ins> parameters given the options available. </ins> A certificate was corrupt, contained signatures that did not verify correctly, etc.
Code change:
As all error alerts are now considered fatal (PR ), we no longer need "This alert is always fatal" explicitly stated everywhere in that section.

Related discussion:
text: certificate, rendering it unacceptable. A field in the handshake was out of range or inconsistent with <del> other fields.  This alert is always fatal. </del> <ins> other fields. </ins> A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not <del> be located or couldn't be matched with a known, trusted CA.  This alert is always fatal. </del> <ins> be located or couldn't be matched with a known, trusted CA. </ins> A valid certificate or PSK was received, but when access control was applied, the sender decided not to proceed with negotiation. <del> This alert is always fatal. </del> A message could not be decoded because some field was out of the specified range or the length of the message was incorrect.  This <del> alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. <del> This alert is always fatal. </del> The protocol version the peer has attempted to negotiate is <del> recognized but not supported.  (For example, old protocol versions might be avoided for security reasons.)  This alert is always fatal. </del> <ins> recognized but not supported. (see backward-compatibility) </ins> Returned instead of "handshake_failure" when a negotiation has failed specifically because the server requires ciphers more <del> secure than those supported by the client.  This alert is always fatal. </del> <ins> secure than those supported by the client. </ins> An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible <del> to continue.  This alert is always fatal. </del> <ins> to continue. </ins> Sent by a server in response to an invalid connection retry <del> attempt from a client. (see [RFC7507]) This alert is always fatal. </del> <ins> attempt from a client. (see [RFC7507]) </ins> Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version. <del> This message is always fatal.  [[TODO: IANA Considerations.]] </del> <ins> [[TODO: IANA Considerations.]] </ins> Sent by endpoints receiving any hello message containing an extension known to be prohibited for inclusion in the given hello message, including any extensions in a ServerHello not first <del> offered in the corresponding ClientHello.  This alert is always fatal. </del> <ins> offered in the corresponding ClientHello. </ins> Sent by servers when unable to obtain a certificate from a URL provided by the client via the "client_certificate_url" extension
Code change:
As all error alerts are now considered fatal (PR ), we no longer need "This alert is always fatal" explicitly stated everywhere in that section.

Related discussion:
text: Sent by servers when a retrieved object does not have the correct hash provided by the client via the "client_certificate_url" <del> extension RFC6066.  This alert is always fatal. </del> <ins> extension RFC6066. </ins> Sent by servers when a PSK cipher suite is selected but no acceptable PSK identity is provided by the client.  Sending this
Code change:
No context and empty context are now declared to be the same. Add some ALL CAPS WORDS for future specifications to deprecate no context. I used SHOULD to forbid no context because, if some protocol currently uses no context, switching it to empty context is a breaking change and probably not worth it. We just want new ones to always provide a context. This affects the rules for using exporters, so RFC 5705 is added to the list of updated documents. Closes issue .

Related discussion:
text: RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  This document replaces the PRF with HKDF, thus requiring a new <del> construction.  The exporter interface remains the same, however the value is computed as: </del> <ins> construction.  The exporter interface remains the same.  If context is provided, the value is computed as: If no context is provided, the value is computed as: Note that providing no context computes the same value as providing an empty context.  As of this document's publication, no allocated exporter label is used with both modes.  Future specifications MUST NOT provide an empty context and no context with the same label and SHOULD provide a context, possibly empty, in all exporter computations. </ins> 8.
Code change:
1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

Related discussion:
text: The key exchange and authentication modes this PSK is allowed to be used with <del> The Application-Layer Protocol Negotiation (ALPN) label(s) </del> <ins> The Application-Layer Protocol Negotiation (ALPN) protocol, if any is to be used </ins> The Server Name Indication (SNI), if any is to be used
Code change:
1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

Related discussion:
text: handshake but reject 0-RTT, and SHOULD NOT take any other action that assumes that this ClientHello is fresh. <del> The parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </del> <ins> The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </ins> 0-RTT messages sent in the first flight have the same content types as their corresponding messages sent in other flights (handshake,
Code change:
1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

Related discussion:
text: with a HelloRetryRequest.  A client MUST NOT include the "early_data" extension in its followup ClientHello. <del> In order to accept early data, the server server MUST have accepted a PSK cipher suite and selected the the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the </del> <ins> In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the </ins> connection during which the ticket was established. The TLS version number, AEAD algorithm, and the hash for HKDF. <del> The selected ALPN RFC7443 value, if any. </del> <ins> The selected ALPN RFC7301 protocol, if any. </ins> Future extensions MUST define their interaction with 0-RTT.
Code change:
1) Switches uses of ALPN label/value to "ALPN protocol" (to clarify this is referring to a single protocol, not the entire extension) 2) Remove plural from external PSK case (if there's not way for the client to select which protocol the 0-RTT data uses, it doesn't make sense for there to be multiple options) 3) Switch reference from RFC7443 to RFC7301 (I assume this is what was intended) I think this makes the intended behavior of the spec a bit more clear.

Related discussion:
text: application MAY opt to retransmit the data once the handshake has been completed.  TLS stacks SHOULD not do this automatically and client applications MUST take care that the negotiated parameters are <del> consistent with those it expected.  For example, if the ALPN value has changed, it is likely unsafe to retransmit the original </del> <ins> consistent with those it expected.  For example, if the selected ALPN protocol has changed, it is likely unsafe to retransmit the original </ins> application layer data. 4.2.9.1.
Code change:
It seems section 4.1.3 Server Hello has not been updated to reflect the new version negotiation mechanism. says "servers says "servers MUST [...] negotiate the highest mutually supported version".
Thanks, I caught a few of these on my reread yesterday too, but I probably missed some too, so keep them coming!

Related discussion:
text: %%% Key Exchange Messages This field contains the version of TLS negotiated for this <del> session.  Servers MUST select the lower of the highest supported server version and the version offered by the client in the ClientHello.  In particular, servers MUST accept ClientHello messages with versions higher than those supported and negotiate the highest mutually supported version.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </del> <ins> session.  Servers MUST select a version from the list in ClientHello.supported_versions extension.  A client which receives a version that was not offered MUST abort the handshake.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </ins> This structure is generated by the server and MUST be generated independently of the ClientHello.random.
Code change:
Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Related discussion:
text: otherwise, a TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher <del> suites. </del> <ins> suites. (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
Code change:
Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Related discussion:
text: Supported Versions ("supported_versions"; supported-versions) <ins> Cookie ("cookie"; cookie) </ins> Signature Algorithms ("signature_algorithms"; signature- algorithms)
Code change:
Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Related discussion:
text: Pre-Shared Key ("pre_shared_key"; pre-shared-key-extension) <del> Cookie ("cookie"; cookie) </del> Server Name Indication ("server_name"; Section 3 of RFC6066) All implementations MUST send and use these extensions when offering
Code change:
Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.

Related discussion:
text: 9. Security issues are discussed throughout this memo, especially in <del> Appendices B, C, and D. </del> <ins> implementation-notes, backward-compatibility, and security-analysis. </ins> 10.
Code change:
Adding "itself" makes the sentence much easier to understand. Actually, two Japanese, who are implementing TLS 1.3 independently, took a long time to understand this.

Related discussion:
text: The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital <del> signatures.  Clients which desire the server to authenticate via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </del> <ins> signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </ins> "signature_algorithms" extension then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions).
Code change:
Ticket is a term that refers to a PSK identity established using an handshake. For out-of-band PSK, we do not use the term.

Related discussion:
text: prevents passive observers from correlating sessions unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even <del> in milliseconds.  External tickets SHOULD use an obfuscated_ticket_age of 0; servers MUST ignore this value for external tickets. </del> <ins> in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </ins> A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension