jiebi/CodeConvo huggingface dataset:
Code change:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Related discussion:
text: 1.2. <del> draft-07 - Integration of semi-ephemeral DH proposal. </del> <ins> draft-08 Remove support for weak and lesser used named curves. Remove support for MD5 and SHA-224 hashes with signatures. draft-07 Integration of semi-ephemeral DH proposal. </ins> Add initial 0-RTT support
Code change:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Related discussion:
text: digital signatures.  The "extension_data" field of this extension contains a "supported_signature_algorithms" value. <del> %%% Signature Algorithm Extension enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </del> <ins> %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </ins> Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated
Code change:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Related discussion:
text: SHA-224, SHA-256, SHA-384, and SHA-512 SHS, respectively.  The "none" value is provided for future extensibility, in case of a signature algorithm which does not require hashing before signing. <ins> The usage of MD5 and SHA-224 are deprecated.  The md5_RESERVED and sha224_RESERVED values MUST NOT be offered or negotiated by any implementation. </ins> This field indicates the signature algorithm that may be used.
Code change:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Related discussion:
text: appropriate rules. If the client supports only the default hash and signature algorithms <del> (listed in this section), it MAY omit the signature_algorithms </del> <ins> (listed in this section), it MAY omit the "signature_algorithms" </ins> extension.  If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key share), it MUST send the <del> signature_algorithms extension, listing the algorithms it is willing to accept. </del> <ins> "signature_algorithms" extension, listing the algorithms it is willing to accept. </ins> <del> If the client does not send the signature_algorithms extension, the </del> <ins> If the client does not send the "signature_algorithms" extension, the </ins> server MUST do the following: If the negotiated key exchange algorithm is one of (DHE_RSA,
Code change:
NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)

Related discussion:
text: 1.2. <del> draft-09 The maximum permittion record expansion for AEAD has been reduced from 2048 to 256 octets. </del> draft-08 Remove support for weak and lesser used named curves.
Code change:
NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)

Related discussion:
text: Revise list of currently available AEAD cipher suites. <ins> Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. </ins> draft-07 Integration of semi-ephemeral DH proposal.
Code change:
NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)

Related discussion:
text: generated. An AEAD cipher MUST NOT produce an expansion of greater than 256 <del> bytes.  An endpoint that receives a record that is larger than 2^14+256 octets MUST generate a fatal "record_overflow" alert. </del> <ins> bytes.  An endpoint that receives a record that is larger than 2^14 + 256 octets MUST generate a fatal "record_overflow" alert. </ins> As a special case, we define the NULL_NULL AEAD cipher which is simply the identity operation and thus provides no security.  This
Code change:
NAME Quick PR for fix noted for PR plus a couple other small nits. Still on draft 08. Fix a typo. ("permittion" is not a word) Consistently use spaces around the "+" in "2^14 + 256". (some did; some didn't)

Related discussion:
text: A TLSCiphertext record was received that had a length more than <del> 2^14+256 bytes, or a record decrypted to a TLSPlaintext record </del> <ins> 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record </ins> 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).
Code change:
I think that the decision was to make this mandatory, since present-but-empty is harder to screw up.
Section 6.2 Figure 1 and others show messages as non-optional. Section 6.3.3 however states that: It seems that the message could indeed be omitted if the server doesn't need to respond with any extensions, but I may be wrong here. We should fix one of the two places though as they contradict each other.

Related discussion:
text: When this message will be sent: <del> If this message is sent, it MUST be sent immediately after the </del> <ins> The EncryptedExtensions message MUST be sent immediately after the </ins> ServerHello message.  This is the first message that is encrypted under keys derived from ES.
Code change:
The text & struct have different names for the config ID. Use the one in the struct.

Related discussion:
text: below). The client specifies the cryptographic configuration for the 0-RTT <del> data using the "configuration", "cipher_suite", and "extensions" </del> <ins> data using the "configuration_id", "cipher_suite", and "extensions" </ins> values.  For configurations received in-band (in a previous TLS connection) the client MUST:
Code change:
You'll also need to update the last paragraph of the MTI Extensions section (currently section 8.2). Now that we're going to be down to only one client-only extension defined in this document, that whole paragraph can probably be cut in favor of a one-off note in the remaining extension's section (signature_algorithms will be the last).
So that the clients can learn about what groups a server supports. The idea here is to allow a client to offer P256 but then learn that a server supports 25519 for next time without the server having to reject.

Related discussion:
text: of the following octets.  Note that the first two octets indicate the extension type ("supported_groups" extension): <ins> As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client.  If the server has a group it prefers to the ones in the "key_share" extension but is still willing to accept the ClientHello, it SHOULD send "supported_groups" to update the client's view of its preferences.  Clients MUST NOT act upon any information found in "supported_groups" prior to successful completion of the handshake, but MAY use the information learned from a successfully completed handshake to change what groups they offer to a server in subsequent connections. </ins> [[TODO: IANA Considerations.]] 6.3.2.3.
Code change:
You'll also need to update the last paragraph of the MTI Extensions section (currently section 8.2). Now that we're going to be down to only one client-only extension defined in this document, that whole paragraph can probably be cut in favor of a one-off note in the remaining extension's section (signature_algorithms will be the last).
So that the clients can learn about what groups a server supports. The idea here is to allow a client to offer P256 but then learn that a server supports 25519 for next time without the server having to reject.

Related discussion:
text: lacking a "server_name" extension with a fatal "missing_extension" alert. <del> Some of these extensions exist only for the client to provide additional data to the server in a backwards-compatible way and thus have no meaning when sent from a server.  The client-only extensions defined in this document are: "signature_algorithms" & "supported_groups".  Servers MUST NOT send these extensions.  Clients receiving any of these extensions MUST respond with a fatal </del> <ins> Servers MUST NOT send the "signature_algorithms" extension; if a client receives this extension it MUST respond with a fatal </ins> "unsupported_extension" alert and close the connection. 9.
Code change:
Some small tweaks and fixes for issue : Move HKDF-Extract citing to a sentence and bring HKDF-Extract with it. Change the Messages arg to HashValue, as the actual hashing is stated in the definition of Derive-Secret which is passing this function a hash, not messages. (fixes issue ) More concise defining of HkdfLabel. Use the word "zeroes" instead of "0s". Edited to add: Also, appended a commit to fix an extra trailing paren.
The other possibility is that a hash of the concatenation of hashes was to be the new HashValue. Simplest change is just to make the arg for what's currently used in the definition and passed in.
NAME Rebased. Is this ok to merge now?
It never actually says that hash_value is H(messages).
This should be clear now.

Related discussion:
text: The TLS handshake establishes one or more input secrets which are combined to create the actual working keying material, as detailed <del> below.  The key derivation process makes use of the following functions, based on HKDF RFC5869: </del> <ins> below.  The key derivation process makes use of the HKDF-Extract and HKDF-Expand functions as defined for HKDF RFC5869, as well as the functions defined below: </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, <del> InputSecret_2, etc.  The initial secret is simply a string of 0s as long as the size of the Hash that is the basis for the HKDF. </del> <ins> InputSecret_2, etc.  The initial secret is simply a string of zeroes as long as the size of the Hash that is the basis for the HKDF. </ins> Concretely, for the present version of TLS 1.3, secrets are added in the following order:
Code change:
We have a registry called "supported groups", and the extension is "supported groups"; but each element is called a "named group" and the data passed in the extension is a "named group list". be consistent in our terminology.

Related discussion:
text: The "extension_data" field of this extension contains a "NamedGroupList" value: <del> %%% Named Group Extension </del> <ins> %%% Supported Groups Extension </ins> Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4
Code change:
On Tuesday, October 11, 2016 08:14:32 pm Martin Thomson wrote: or missing_extension
I think that missingextension would be OK, but we would hit the lower-level decodeerror first, since HRR is defined with:

Related discussion:
text: Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake <del> with a "decode_error" alert.  Clients SHOULD abort the handshake with an "unexpected message" if the HelloRetryRequest would not result in any change in the ClientHello or in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </del> <ins> with a "decode_error" alert.  Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello.  If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an "unexpected_message" alert. </ins> Otherwise, the client MUST process all extensions in the HelloRetryRequest and send a second updated ClientHello.  The
Code change:
Variants is not a subsection of Constants; just have them all be subsections of same depth within Presentation Language URL

Related discussion:
text: Fields and variables may be assigned a fixed value using "=", as in: <del> 3.7.1. </del> <ins> 3.8. </ins> Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated
Code change:
The handshake context here is just the transcript of the handshake messages, not the hash of the transcript. The language makes it seem like the authentication messages are Hash(Hash(handshake messages) + Certificate), etc.

Related discussion:
text: The certificate and signing key to be used. <del> A Handshake Context based on the hash of the handshake messages </del> <ins> A Handshake Context based on the transcript of the handshake messages </ins> A base key to be used to compute a MAC key.
Code change:
Move the list to the new transcript hash section. Note that EndOfEarlyData goes in the client Handshake Context.
lgtm

Related discussion:
text: in the cookie, rather than requiring it to export the entire intermediate hash state (see cookie). <ins> For concreteness, the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </ins> In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash.  Note, however, that subsequent post-handshake authentications do not
Code change:
Move the list to the new transcript hash section. Note that EndOfEarlyData goes in the client Handshake Context.
lgtm

Related discussion:
text: Secret is called with four distinct transcripts; in a 1-RTT-only exchange with three distinct transcripts. <del> The complete transcript passed to Derive-Secret is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </del> If a given secret is not available, then the 0-value consisting of a string of Hash.length zero bytes is used.  Note that this does not mean skipping rounds, so if PSK is not in use Early Secret will still
Code change:
Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. NAME would love your feedback.
Shouldn't "TLS 1.3, " be shortened to "tls13 "? Without that, several of the labels would seem to blow blocks. Also, "derived secret" seems unchanged, and is too long to fit into a block, even with "tls13 " prefix.
Oops. Good catch. Script fail.
NAME fixed?
Yeah, I'll add a note. I still have an issue for the ChangeLog so I will add this as well
Also, minimum label size looks to be still 10, presumably should be 7 with 6-byte prefix (as it 10 with 9-byte prefix).

Related discussion:
text: Add "post_handshake_auth" extension to negotiate post-handshake authentication (*). <ins> Shorten labels for HKDF-Expand-Label so that we can fit within one compression block (*). </ins> draft-19 Hash context_value input to Exporters (*)
Code change:
Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. NAME would love your feedback.
Shouldn't "TLS 1.3, " be shortened to "tls13 "? Without that, several of the labels would seem to blow blocks. Also, "derived secret" seems unchanged, and is too long to fit into a block, even with "tls13 " prefix.
Oops. Good catch. Script fail.
NAME fixed?
Yeah, I'll add a note. I still have an issue for the ChangeLog so I will add this as well
Also, minimum label size looks to be still 10, presumably should be 7 with 6-byte prefix (as it 10 with 9-byte prefix).

Related discussion:
text: layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label. <ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute. The labels in this specification have all been chosen to fit within this limit. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2, etc.  The initial secret is simply a string of
Code change:
Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. NAME would love your feedback.
Shouldn't "TLS 1.3, " be shortened to "tls13 "? Without that, several of the labels would seem to blow blocks. Also, "derived secret" seems unchanged, and is too long to fit into a block, even with "tls13 " prefix.
Oops. Good catch. Script fail.
NAME fixed?
Yeah, I'll add a note. I still have an issue for the ChangeLog so I will add this as well
Also, minimum label size looks to be still 10, presumably should be 7 with 6-byte prefix (as it 10 with 9-byte prefix).

Related discussion:
text: mean skipping rounds, so if PSK is not in use Early Secret will still be HKDF-Extract(0, 0).  For the computation of the binder_secret, the label is "external psk binder key" for external PSKs (those <del> provisioned outside of TLS) and "resumption psk binder key" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del> <ins> provisioned outside of TLS) and "res binder" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </ins> There are multiple potential Early Secret values depending on which PSK the server ultimately selects.  The client will need to compute