jiebi/CodeConvo huggingface dataset:
Code change:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

Related discussion:
text: server implementation declines all PSK identities with different SNI values, these two values are always the same. <del> Note: Although the resumption main secret depends on the client's second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript </del> <ins> Note: Although the resumption ecret depends on the client's second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript </ins> independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to
Code change:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

Related discussion:
text: In this version of TLS 1.3, the two input secrets are: PSK (a pre-shared key established externally or derived from the <del> resumption_main_secret value from a previous connection) </del> <ins> resumption_secret value from a previous connection) </ins> (EC)DHE shared secret (ecdhe-shared-secret-calculation)
Code change:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

Related discussion:
text: will still be HKDF-Extract(0, 0).  For the computation of the binder_key, the label is "ext binder" for external PSKs (those provisioned outside of TLS) and "res binder" for resumption PSKs <del> (those provisioned as the resumption main secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del> <ins> (those provisioned as the resumption 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
Code change:
While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)

Related discussion:
text: The exporter value is computed as: <del> Where Secret is either the early_exporter_main_secret or the exporter_main_secret.  Implementations MUST use the exporter_main_secret unless explicitly specified by the application. The early_exporter_main_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </del> <ins> Where Secret is either the early_exporter_secret or the exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  The early_exporter_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </ins> If no context is provided, the context_value is zero length. Consequently, providing no context computes the same value as
Code change:
MGF1 got unhelpfully spelled out as "mask generation function 1" in RFC 8446. I'm guessing this is the result of an acronym expansion editting pass, but the function is simply called "MGF1". There is no such thing as "mask generation function 1". Correct this back to MGF1. In hopes this doesn't get hit the same editing pass later, I've tweaked the wording and moved the citation so that "mask generation function" is still uttered before MGF1, and it's clearer that both primitives are defined in RFC 8017.

Related discussion:
text: signature is represented as a DER-encoded X690 ECDSA-Sig-Value structure as defined in RFC4492. <del> Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the Salt MUST be equal to the length of the output of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the rsaEncryption OID RFC5280. </del> <ins> Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest used in MGF1 and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the Salt MUST be equal to the length of the output of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the rsaEncryption OID RFC5280. </ins> Indicates a signature algorithm using EdDSA as defined in RFC8032 or its successors.  Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants. <del> Indicates a signature algorithm using RSASSA-PSS RFC8017 with mask generation function 1.  The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the Salt MUST be equal to the length of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's parameters are present, then the parameters in the signature MUST be identical to those in the public key. </del> <ins> Indicates a signature algorithm using RSASSA-PSS with a mask generation function of MGF1, as defined in RFC8017.  The digest used in MGF1 and the digest being signed are both the corresponding hash algorithm as defined in SHS.  The length of the Salt MUST be equal to the length of the digest algorithm.  If the public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's parameters are present, then the parameters in the signature MUST be identical to those in the public key. </ins> Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used
Code change:
Just a few things I noticed that I think make it a little bit easier to follow. Name resumption_secret consistently when used Show full legend for each handshake flow Simplify/clarify secret sources table a bit and make text cases consistent The resumption secret naming was also apparently noticed by NAME in issue . (Edited to note: this PR has been pruned down to a smaller list of changes; see commit message)
Ok, to respond to comments I've pushed a new commit. RE: capitalization: Upper or lower is fine, as long as it's consistent. I've switched it to all upper (title case) instead of all lower. RE: legend repetition: If you're just reading one section, e.g. got to it via TOC, you might not have seen the legend (recently). I've made it less wordy now and also added a line to indicate "+" is for extensions, as I realized that wasn't necessarily clear. (and added a "+" where the notation was inconsistent) We do have an extension that was previously a message, now. The basic point is consistency; make each handshake flow make sense on its own. I think repeating the legend is helpful, but if you really don't want to repeat it that I can cut this down to just the little stuff and table. Showing "N/A" instead of repeating things in the table is the most helpful part here, I think. It states that SS=ES in some circumstances elsewhere, but the table isn't clear that these are the exact same values, especially because the extracted ones are not.
Edited again and repushed for some more naming consistency.
Revised & rebased. Of note, I think these changes to the table make it far easier to see what's going on here.
NAME If you're going to be rewriting this, I'll just set those parts aside. The commit here is now just the little stuff: fix the spacing, add a line stating what SS/ES are in the list of derivations, and fix "shared_secret" (there's no such value named that; just drop the underscore).
NAME commit updated with fixes for your comments above
The key derivation process uses the "master secret" as the basis for application traffic keys and both the resumption and exporter secrets. There are lots of other secrets though. I don't have a better name right now, so close this if none better can be found. Also s/resumption master secret/resumption secret/ throughout, it's a little inconsistent.
Now master of more

Related discussion:
text: shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF RFC5869. </del> <ins> the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above.  Whilst SS and ES may be the same in some cases, the extracted xSS and xES will not. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.
Code change:
Just a few things I noticed that I think make it a little bit easier to follow. Name resumption_secret consistently when used Show full legend for each handshake flow Simplify/clarify secret sources table a bit and make text cases consistent The resumption secret naming was also apparently noticed by NAME in issue . (Edited to note: this PR has been pruned down to a smaller list of changes; see commit message)
Ok, to respond to comments I've pushed a new commit. RE: capitalization: Upper or lower is fine, as long as it's consistent. I've switched it to all upper (title case) instead of all lower. RE: legend repetition: If you're just reading one section, e.g. got to it via TOC, you might not have seen the legend (recently). I've made it less wordy now and also added a line to indicate "+" is for extensions, as I realized that wasn't necessarily clear. (and added a "+" where the notation was inconsistent) We do have an extension that was previously a message, now. The basic point is consistency; make each handshake flow make sense on its own. I think repeating the legend is helpful, but if you really don't want to repeat it that I can cut this down to just the little stuff and table. Showing "N/A" instead of repeating things in the table is the most helpful part here, I think. It states that SS=ES in some circumstances elsewhere, but the table isn't clear that these are the exact same values, especially because the extracted ones are not.
Edited again and repushed for some more naming consistency.
Revised & rebased. Of note, I think these changes to the table make it far easier to see what's going on here.
NAME If you're going to be rewriting this, I'll just set those parts aside. The commit here is now just the little stuff: fix the spacing, add a line stating what SS/ES are in the list of derivations, and fix "shared_secret" (there's no such value named that; just drop the underscore).
NAME commit updated with fixes for your comments above
The key derivation process uses the "master secret" as the basis for application traffic keys and both the resumption and exporter secrets. There are lots of other secrets though. I don't have a better name right now, so close this if none better can be found. Also s/resumption master secret/resumption secret/ throughout, it's a little inconsistent.
Now master of more

Related discussion:
text: 7.2.2. A conventional Diffie-Hellman computation is performed.  The <del> negotiated key (Z) is used as the shared_secret, and is used in the </del> <ins> negotiated key (Z) is used as the shared secret, and is used in the </ins> key schedule as specified above.  Leading bytes of Z that contain all zero bits are stripped before it is used as the input to HKDF.
Code change:
The current wording at the end of the section on resumption and PSK should be changed to indicate that if a server declines resumption then a full handshake, including the server Certificate and CertificateVerify messages, should take place. In its current state, the comment on omission of these messages is not disjoint from the statement regarding the server's rejection of resumption.

Related discussion:
text: tls-resumption-psk shows a pair of handshakes in which the first establishes a PSK and the second uses it: <del> Note that the client supplies a ClientKeyShare to the server as well, which allows the server to decline resumption and fall back to a full handshake.  However, because the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify.  PSK-based resumption cannot be used to provide a new ServerConfiguration. </del> <ins> As the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify.  PSK-based resumption cannot be used to provide a new ServerConfiguration.  Note that the client supplies a ClientKeyShare to the server as well, which allows the server to decline resumption and fall back to a full handshake. </ins> The contents and significance of each message will be presented in detail in the following sections.
Code change:
LGTM
Hubert Karlo writes: And how does the client know that the algorithms came from the server. We should have a "client MUST wait for the full handshake to finish before recording this information" or we will have a very nice cipher downgrade. Just having it signed is likely not a good idea, as they may depend on ciphersuites advertised by client.
Since the ServerConfiguration and the suites are covered by the signature the server provides, isn't it safe to use the configuration add soon as you have verified the server identity?
n.b., I have no problem with mandating that clients wait for finished, because it is immediately after the signature, but I wasn't the properties to be clear.

Related discussion:
text: send a Certificate message and a CertificateVerify message, even if the "known_configuration" extension was used for this handshake, thus requiring a signature over the configuration before it can be used by <del> the client. </del> <ins> the client.  Clients MUST not rely on the ServerConfiguration message until successfully receiving and processing the server's Certificate, CertificateVerify, and Finished.  If there is a failure in processing those messages, the client MUST discard the ServerConfiguration. </ins> 6.3.8.
Code change:
NAME did a massive message->alert change a while back and I did yet more when we were rebasing his patch. Looks like there's more up here in Closure Alerts. We're referring to alerts, not the messages that carry them. Switch to "alerts" instead to remain consistent with the rest of the document, notably the following section.

Related discussion:
text: close a connection does not prohibit a session from being resumed. <del> This message notifies the recipient that the sender will not send </del> <ins> This alert notifies the recipient that the sender will not send </ins> any more messages on this connection.  Any data received after a closure MUST be ignored. <del> This message is sent by the client to indicate that all 0-RTT </del> <ins> This alert is sent by the client to indicate that all 0-RTT </ins> application_data messages have been transmitted and that the next message will be handshake message protected with the 1-RTT handshake keys.  This alert MUST be at the warning level.  Servers <del> MUST NOT send this message and clients receiving this message MUST </del> <ins> MUST NOT send this alert and clients receiving this alert MUST </ins> terminate the connection with an "unexpected_message" alert. <del> This message notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just </del> <ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just </ins> closing the connection by sending a "close_notify" is more appropriate.  This alert SHOULD be followed by a "close_notify". This alert is generally a warning.
Code change:
Cleaned up references to knownconfiguration extension (merged into earlydata in draft-08)

Related discussion:
text: ServerConfiguration format. The semantics of this message are to establish a shared state between <del> the client and server for use with the "known_configuration" extension with the key specified in key and with the handshake </del> <ins> the client and server for use with the "early_data" extension with the key specified in "static_key_share" and with the handshake </ins> parameters negotiated by this handshake. When the ServerConfiguration message is sent, the server MUST also send a Certificate message and a CertificateVerify message, even if <del> the "known_configuration" extension was used for this handshake, thus </del> <ins> the "early_data" extension was used for this handshake, thus </ins> requiring a signature over the configuration before it can be used by the client.  Clients MUST NOT rely on the ServerConfiguration message until successfully receiving and processing the server's Certificate,
Code change:
Minor editorial tweaks. I just noticed the extra line that gets left in there when shown up top (two lines between first two shown blocks, instead of one). This fixes that. Also drops the periods after the comments, as they're not sentences.

Related discussion:
text: "supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { // RSASSA-PKCS-v1_5 <del> algorithms.  rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </del> <ins> algorithms rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </ins> rsa_pkcs1_sha384 (0x0501), rsa_pkcs1_sha512 (0x0601), Note: This production is named "SignatureScheme" because there is
Code change:
The draft was in a sort of halfway state between whether TLSCiphertext has a fragment that is a selection or just embedding the AEAD elements directly. This should normalize it to the embedded view without the extra GenericAEADCipher struct definition. (i don't think this changes the logic of the draft at all)

Related discussion:
text: described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key. The type field is identical to TLSPlaintext.type. The version field is identical to TLSPlaintext.version. The length (in bytes) of the following TLSCiphertext.fragment. The length MUST NOT exceed 2^14 + 2048. The AEAD encrypted form of TLSPlaintext.fragment. Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the <del> GenericAEADCipher.nonce_explicit part.  In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of RFC5116; with record_iv_length being the length of the explicit part.  In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in key-calculation), and the explicit part is included in </del> <ins> TLSCiphertext.nonce_explicit part.  In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of RFC5116; with record_iv_length being the length of the explicit part.  In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in key-calculation), and the explicit part is included in </ins> GenericAEAEDCipher.nonce_explicit. The plaintext is the TLSPlaintext.fragment.