Remove support for MD5 and SHA-224 hashes with signatures. <del> Revise list of currently available AEAD cipher suites. </del>  Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. to continue.  This alert is always fatal.  This alert was used in previous versions of TLS.  TLS 1.3 does not include renegotiation and TLS 1.3 implementations MUST NOT send this alert when in TLS 1.3 mode.  This alert is always fatal.  Sent by clients that receive an extended ServerHello containing an extension that they did not put in the corresponding ClientHello. This alert is always fatal.  New Alert values are assigned by IANA as described in iana- considerations. algorithms.  server-certificate and server-key-share describe the appropriate rules. <del> If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the "signature_algorithms" 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 "signature_algorithms" extension, listing the algorithms it is willing to accept. If the client does not send the "signature_algorithms" extension, the server MUST do the following: If the negotiated key exchange algorithm is one of (DHE_RSA, ECDHE_RSA), behave as if client had sent the value {sha1,rsa}. If the negotiated key exchange algorithm is DHE_DSS, behave as if the client had sent the value {sha1,dsa}. If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as if the client had sent value {sha1,ecdsa}. Note: This extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in RFC6066 require servers to ignore extensions they do not understand. </del>  Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension.  6.3.2.2. When sent by the client, the "supported_groups" extension indicates instance, if a client supplies only ECDHE groups, the server MUST NOT negotiate finite field Diffie-Hellman.  If no acceptable group can be selected across all cipher suites, then the server MUST generate a <del> fatal "handshake_failure" alert. </del>  NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) presence of the server_name extension, clients SHOULD send this extension. <del> If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/ signature algorithm pair that appears in that extension.  Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). </del>  If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such implementation need only maintain one running hash per hash type for CertificateVerify, Finished and other messages. <del> If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension.  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.  In order to negotiate correctly, the server MUST check any candidate cipher suites against the "signature_algorithms" extension before selecting them.  This is somewhat inelegant but is a compromise designed to minimize changes to the original cipher suite design. </del>  In addition, the hash and signature algorithms MUST be compatible with the key in the server's end-entity certificate.  RSA keys MAY 8.  In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TODO:Needs to be selected [1].  (See cipher-suites for the definition.)  9. Application data messages are carried by the record layer and are

This is a set of changes covering mailing list discussions about error alerts, certificate acceptance, SHA-1 deprecation, as well as including some recommendations about curves. There's also quite a few other little fixes mixed in there, including some cleanups in RFC2119 language. The alerts list has been fully updated to include all standardized alerts (PSK alert is needed for new PSK extension, in particular). This also adds RFC 5746 ("renegotiation_info" info extension) to the list of newly obsoleted RFCs, as renegotiation has already been removed completely thus making it no longer applicable as of this new TLS version. PR has the discussed change to certificate ordering requirements, however it is waiting on NAME to assess consensus so I'm not including it here. (Edited to note: final commits from this PR have changed and parts have been broken off into other branches for other PRs)
NAME I pushed a new commit here to address your comments. I've changed SHA1 to a SHOULD NOT except for backwards compatibility and added explicit error cases for if the other two extensions are missing (better explicit than implicit).
Yes, I was looking for the explicit description to send alerts in that case. I like those changes. :+1:
Rebased and squashed a little bit.
Line 2011 in e4f5ae5: it's missing the information the client MUST abort the handshake with alert if the server sends a extension not advertised by client (that does duplicate paragraph from line 2101) Line 2065 in e4f5ae5: the client MUST abort the handshake with in case the selected values don't match HelloRetryRequest. Line 2293 in e4f5ae5: as the client may advertise the obsolete curves for backwards compatibility (there are servers which will accept only those curves), the client MUST check if the server hasn't selected one the backwards-compatible curves in TLS1.3 and abort the connection Line 3905 in e4f5ae5: it's missing that the server receiving SSLv2 type client hello with TLS1.3 version, MUST abort connection with alert I think we should be explicit in saying that the server MUST accept Client Hello message with version field higher than 3, 4 but process it as if it was set to 3, 4.
NAME Comments addressed in a new commit pushed here. The only two comments I didn't change something for are: I think "SHOULD" is acceptable for duplicate ClientKeyShareOffers checking, as that actually requires a little bit of effort for not much gain. Not strongly against a "MUST" though. I'm leaving MD5 at a total ban and expectation of fatal error, because it's garbage. I know the hash is meaningless in the context of trust anchors, but any exception to the rule of "if you see MD5, kill it" is too much of an exception at this point. (note that this does not apply to SHA1+MD5 in the context of old TLS versions, which is ugly but acceptable for backwards compatibility for now) Edit: Latest commit has this plus yet more error cases.
Latest commit adds a couple new error alerts so that the current catchall of "handshake_failure" can be better broken up into individual specialized errors to make debugging and deciding what error message to show to users easier.
I've split out all the purely editorial stuff into PR to reduce the size of this notably. This is based on top of that (the first two commits are that PR). Most of the changesets are relatively narrow in focus, now. Each commit can be reviewed more or less separately before merging the whole PR. Having them all here means not having to handle nearly as many merge conflicts, because lots of these modify similar areas.
Rebased on top of master now that the editorial bits are merged.
NAME Ok, this has now been pruned down to the first two commits, which covers just the MTI extensions and updating of the alerts registry (just updating the documentation with the current standards). The other stuff is in another branch which I'll submit as a new PR after this part is dealt with. GitHub forgot NAME comments above, as they were on the old commit itself rather than technically on the PR (an annoying habbit of GitHub, apparently). Still all here: URL I've cut the allowed assumption of the TLS 1.2 SHA1 defaults when the extension isn't sent. The rest of the issues center on whether the TLC BCP is supposed to be the current standard set of expectations or not, as that's pretty much all in line with that RFC. URL
There's certainly not WG consensus that the UTA BCP applies to TLS as a whole, so this is not the time to merge those requirements in. Feel free to start a message on the mailing list, but I need to get -08 out so it's going to have to wait
Understood. I'll split them off, then. Shouldn't take long.
"Understood. I'll split them off, then. Shouldn't take long." Thanks. I'm about to shut down for the night but I'll deal with this tomorrow aM.
Ok, commit updated on this PR: cut out SNI & RI bits changed TLS 1.2 back-compat language to your suggestion lowered threshold for sending missingextension in response to no supportedgroups to only the case where it already causes a handshakefailure (e.g. just use the new more precise error code when the server knows that the extension is missing) added "open issue" notes changed the DSA->ECDSA in the example expanded on truncated HMAC bit, though I didn't go as far as citing the specific paper on its security (BCP does that); as noted, it's N/A for AEAD, anyway Took a little bit extra time to double-check that I got everything you and Travis wanted changed. (it wanted an informative ref listing for the TLS 1.2 spec, which we apparently didn't have in the current version) GitHub's comment system is beginning to annoy me, btw. :| I haven't added in the MTI bits for the clientkeyshare & preshared_key extensions that are in the larger branch, as you didn't review those yet, so just a note for now. This is also rebased onto current master and I made sure the second commit is documentation only (the bulk of the changed lines are just shifting whitespace so they all fit).
There are a couple of places in the spec where it says client/server MUST not do x but doesn't specify what happens if they do. Should we specify that behavior? Some examples: s7.3.2: Clients MUST NOT offer multiple ClientKeyShareOffers for the same parameters. s7.3.2.5: There MUST NOT be more than one extension of the same type. s7.3.2.5.1: signature ... It MUST NOT appear in this extension. and Servers MUST NOT send this extension. s7.3.2.5.3: If the EarlyData extension is used, then clients MUST NOT send any messages other than the ClientHello in their initial flight. and Servers MUST NOT send the EarlyData extension. sA.4: TLSNULLWITHNULLNULL is specified and is the initial state of a TLS connection during the first handshake on that channel, but MUST NOT be negotiated, as it provides no more protection than an unsecured connection.
Sounds like a good idea. I assume that the proper response is for the peer to send a fatal alert, but specifying exactly what alert is probably a good idea.
This is addressed in PR .
We should just require it.
I agree with that, it might go also with potentially deleting the SignatureAlgorithm from the new ciphersuites. By the way, shouldn't we consider also removing MD5 from HashAlgorithms even if it is used a lot (I don't know the numbers on that ...) ?
PR mandates usage of this extension and also adds an explicit error expectation for MD5 (it's already listed as deprecated in the current draft).
NAME This should be closable now.

Remove support for MD5 and SHA-224 hashes with signatures.  <ins> Update lists of available AEAD cipher suites and error alerts. </ins> Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. to continue.  This alert is always fatal. <ins> Sent by a server in response to an invalid connection retry attempt from a client. (see RFC7507) This alert is always fatal. </ins> This alert was used in previous versions of TLS.  TLS 1.3 does not include renegotiation and TLS 1.3 implementations MUST NOT send this alert when in TLS 1.3 mode.  This alert is always fatal. <ins> Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version. This message is always fatal.  [[TODO: IANA Considerations.]] </ins> Sent by clients that receive an extended ServerHello containing an extension that they did not put in the corresponding ClientHello. This alert is always fatal. <ins> Sent by servers when unable to obtain a certificate from a URL provided by the client via the "client_certificate_url" extension RFC6066. Sent by servers when no server exists identified by the name provided by the client via the "server_name" extension RFC6066. Sent by clients when an invalid or unacceptable OCSP response is provided by the server via the "status_request" extension RFC6066. This alert is always fatal. Sent by servers when a retreived object does not have the correct hash provided by the client via the "client_certificate_url" extension RFC6066.  This alert is always fatal. Sent by servers when an unknown PSK identity is provided by the client.  Sending this alert is OPTIONAL; servers MAY instead choose to send a "decrypt_error" alert to merely indicate an invalid PSK identity. </ins> New Alert values are assigned by IANA as described in iana- considerations. algorithms.  server-certificate and server-key-share describe the appropriate rules.  <ins> All clients MUST send a valid "signature_algorithms" extension in their ClientHello when offering certificate authenticated cipher suites.  Servers receiving a TLS 1.3 ClientHello offering certificate authenticated cipher suites without this extension MUST send a "missing_extension" alert message and close the connection. </ins> Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension. <ins> Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not contain this extension.  If those servers are willing to negotiate TLS 1.2, they MUST behave in accordance with the requirements of RFC5246. </ins> 6.3.2.2. When sent by the client, the "supported_groups" extension indicates instance, if a client supplies only ECDHE groups, the server MUST NOT negotiate finite field Diffie-Hellman.  If no acceptable group can be selected across all cipher suites, then the server MUST generate a  <ins> fatal "handshake_failure" alert, or a "missing_extension" alert if no extension was provided. </ins> NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) presence of the server_name extension, clients SHOULD send this extension.  <ins> All certificates provided by the server MUST be signed by a hash/ signature algorithm pair that appears in the "signature_algorithms" extension provided by the client (see signature-algorithms).  [[OPEN ISSUE: changing this is under consideration]] Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a ECDSA key). </ins> If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such implementation need only maintain one running hash per hash type for CertificateVerify, Finished and other messages.  <ins> The signature algorithm and hash algorithm MUST be a pair offered in the "signature_algorithms" extension (see signature- 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. In order to negotiate correctly, the server MUST check any candidate cipher suites against the "signature_algorithms" extension before selecting them.  This is somewhat inelegant but is a compromise designed to minimize changes to the original cipher suite design. </ins> In addition, the hash and signature algorithms MUST be compatible with the key in the server's end-entity certificate.  RSA keys MAY 8. <ins> 8.1. </ins> In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TODO:Needs to be selected [1].  (See cipher-suites for the definition.) <ins> 8.2. In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the following TLS extensions: Signature Algorithms ("signature_algorithms"; signature- algorithms) Negotiated Groups ("supported_groups"; negotiated-groups) All implementations MUST use the "signature_algorithms" extension when offering and negotiating certificate authenticated cipher suites.  All implementations MUST use the "supported_groups" extension when offering and negotiating DHE or ECDHE cipher suites. [[TODO: also note client_key_share & pre_shared_key extensions]] [[OPEN ISSUE: MTI SNI under consideration]] </ins> 9. Application data messages are carried by the record layer and are


1.2.  draft-08 Remove support for weak and lesser used named curves. The length (in bytes) of the following TLSCiphertext.fragment. <del> The length MUST NOT exceed 2^14 + 2048. </del>  The AEAD encrypted form of TLSPlaintext.fragment. encryption operation.  The length will generally be larger than TLSPlaintext.length, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of <del> overhead could vary with different TLSPlaintext.length values.  Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. </del>  Symbolically, <del> [[OPEN ISSUE: Reduce these values? https://github.com/tlswg/tls13- spec/issues/55]] </del> In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the If the decryption fails, a fatal "bad_record_mac" alert MUST be generated.  As a special case, we define the NULL_NULL AEAD cipher which is simply the identity operation and thus provides no security.  This cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL A TLSCiphertext record was received that had a length more than <del> 2^14+2048 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).

As discussed on list.
Minor suggestions: 1) Explicitly specify the expectation of a "record_overflow" alert after the two "MUST NOT"s. 2) Also drop the issue "OPEN ISSUE" note that's on line 1087-1088. 3) Amend the changelog to mention this. 4) Add a sentence noting the overhead cap has changed to the "Note: In versions of TLS prior to 1.3" paragraph, or elsewhere.
As NAME suggests, I've updated the PR. I have not added the Note. I don't like those. The change log is enough.
Why was the changelog amended as for draft-09? The draft-08 hasn't been published yet. Is it in the progress of being released? (not shown on DataTracker and releases haven't been tagged on GitHub since draft-05)
Pilot error. Please feel free to submit a PR. , Dave Garrett EMAIL wrote:
This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later. This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.
Proposal at interim: 256 octets total.

1.2. <ins> draft-09 The maximum permittion record expansion for AEAD has been reduced from 2048 to 256 octets. </ins> draft-08 Remove support for weak and lesser used named curves. The length (in bytes) of the following TLSCiphertext.fragment.  <ins> The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST generate a fatal "record_overflow" alert. </ins> The AEAD encrypted form of TLSPlaintext.fragment. encryption operation.  The length will generally be larger than TLSPlaintext.length, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of  <ins> overhead could vary with different TLSPlaintext.length values. </ins> Symbolically,  In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the If the decryption fails, a fatal "bad_record_mac" alert MUST be generated. <ins> An AEAD cipher MUST NOT produce an expansion of greater than 256 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 cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL A TLSCiphertext record was received that had a length more than  <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).


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>  This field is a placeholder for future extensions to the

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.

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  <ins> requested a certificate on this handshake.  [[OPEN ISSUE: Should we relax this?]] </ins> This field is a placeholder for future extensions to the


This message is always fatal.  [[TODO: IANA Considerations.]] <del> Sent by clients that receive an extended ServerHello containing an extension that they did not put in the corresponding ClientHello. This alert is always fatal. </del>  Sent by servers when unable to obtain a certificate from a URL the server which signature/hash algorithm pairs may be used in digital signatures.  The "extension_data" field of this extension contains a "supported_signature_algorithms" value: algorithms.  server-certificate and server-key-share describe the appropriate rules. <del> All clients MUST send a valid "signature_algorithms" extension in their ClientHello when offering certificate authenticated cipher suites.  Servers receiving a TLS 1.3 ClientHello offering certificate authenticated cipher suites without this extension MUST send a "missing_extension" alert message and close the connection. Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension. </del> Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not contain this extension.  If those servers are willing to negotiate TLS 1.2, they MUST behave in accordance with the requirements of "elliptic_curves" and only contained elliptic curve groups.  See RFC4492 and I-D.ietf-tls-negotiated-ff-dhe.  The "extension_data" field of this extension contains a "NamedGroupList" value: of the following octets.  Note that the first two octets indicate the extension type (Supported Group Extension): <del> The client MUST supply a "supported_groups" extension containing at least one group for each key exchange algorithm (currently DHE and ECDHE) for which it offers a cipher suite.  If the client does not supply a "supported_groups" extension with a compatible group, the server MUST NOT negotiate a cipher suite of the relevant type.  For instance, if a client supplies only ECDHE groups, the server MUST NOT negotiate finite field Diffie-Hellman.  If no acceptable group can be selected across all cipher suites, then the server MUST generate a fatal "handshake_failure" alert, or a "missing_extension" alert if no extension was provided. </del> NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyShare message.  The server 6.3.2.3. <del> The "client_key_share" extension MUST be provided by the client if it offers any cipher suites that involve non-PSK (currently DHE or ECDHE) key exchange.  It contains the client's cryptographic parameters for zero or more key establishment methods.  [[OPEN ISSUE: Would it be better to omit it if it's empty?. </del>  https://github.com/tlswg/tls13-spec/issues/190]] %%% Key Exchange Messages struct { NamedGroup group; opaque multiple integer DH groups.  The shares for each ClientKeyShareOffer MUST by generated independently.  Clients MUST NOT offer multiple ClientKeyShareOffers for the same parameters.  It is explicitly <del> permitted to send an empty client_key_share extension as this is used to elicit the server's parameters if the client has no useful information.  [TODO: Recommendation about what the client offers. Presumably which integer DH groups and which curves.] </del>  6.3.2.3.1. the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background).  The "extension_data" field of this extension contains a "PreSharedKeyExtension" value: An opaque label for the pre-shared key. <del> When the client offers a PSK cipher suite, it MUST also supply a PreSharedKeyExtension to indicate the PSK(s) to be used.  If no such extension is present, the server MUST NOT negotiate a PSK cipher suite.  If no suitable identity is present, the server MUST NOT negotiate a PSK cipher suite. </del>  If the server selects a PSK cipher suite, it MUST send a PreSharedKeyExtension with the identity that it selected.  The client MUST verify that the server has selected one of the identities that the client supplied.  If any other identity is returned, the client <del> MUST generate a fatal "handshake_failure" alert. </del>  6.3.2.5. Negotiated Groups ("supported_groups"; negotiated-groups) <del> All implementations MUST use the "signature_algorithms" extension when offering and negotiating certificate authenticated cipher suites.  All implementations MUST use the "supported_groups" extension when offering and negotiating DHE or ECDHE cipher suites. </del>  <del> [[TODO: also note client_key_share & pre_shared_key extensions]] [[OPEN ISSUE: MTI SNI under consideration]] </del>  9.

Modified extension requirements based on recent list discussion. It's a little verbose with repeated boilerplate, but it's clear no matter which section you read now. I've also moved the relevant requirements up top to a consistent place for each extension's section. The level of strictness here is now: If attempting to negotiate and the mandatory extension isn't available: MUST error If just detecting an invalid combination, but not actively negotiating: MAY error SNI is clearly listed as MUST support, servers MAY require, and SHOULD error if required The "unsupportedextension" alert is reworded more generally and put in as the consequence for violating the pre-existing "MUST NOT" send the client-only extensions from a server requirements. Also added some more, namely the fact that "clientkey_share" is clearly an error to be sent from a server.
NAME & NAME Please take a look when you get a chance. Are we all on the same page with this language? Anything that needs tweaking to focus on the above better? Edited to add: Also, do I need to cut out SNI again, or is this wording ok? It's not requiring it to be sent, just noting it must be supported, which was agreed to on list a while ago, and noting the existing case that servers MAY require it with a way to indicate it using the new error alert.
NAME New commit pushed here with changes for your comments: "invalid" -> "prohibited" Text is now: "Servers MUST NOT negotiate use of cipher suites unless the client supplies a supported . If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert." So, trying to find a viable cipher suite is preferred and the error is only required when there's nothing else to do. Edited to note: The latter doesn't contradict the mandatory error on negotiation without the needed extension, as the server simply has the (unlikely) chance of negotiating something completely different instead. The MAY error is still included later in the changeset, as discussed, so clients are still expected to always do this correctly or risk the server throwing an error.
NAME Ok, repushed with one-word change to clarify to "at least one group for each ephemeral key exchange algorithm". This excludes PSK, but is still fine for (EC)DHE when used with it. Seems like the simplest fix.

This message is always fatal.  [[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 offered in the corresponding ClientHello.  This alert is always fatal. </ins> Sent by servers when unable to obtain a certificate from a URL the server which signature/hash algorithm pairs may be used in digital signatures. <ins> All clients MUST send a valid "signature_algorithms" extension containing at least one supported SignatureAndHashAlgorithm when offering any certificate authenticated cipher suites.  Servers MUST NOT negotiate use of a certificate authenticated cipher suite unless the client supplies a supported SignatureAndHashAlgorithm.  If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert.  (see mti-extensions) Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension.  Clients receiving this extension MUST respond with an "unsupported_extension" alert and close the connection. </ins> The "extension_data" field of this extension contains a "supported_signature_algorithms" value: algorithms.  server-certificate and server-key-share describe the appropriate rules.  Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not contain this extension.  If those servers are willing to negotiate TLS 1.2, they MUST behave in accordance with the requirements of "elliptic_curves" and only contained elliptic curve groups.  See RFC4492 and I-D.ietf-tls-negotiated-ff-dhe. <ins> All clients MUST send a valid "supported_groups" extension containing at least one group for each ephemeral key exchange algorithm (currently DHE and ECDHE) for which it offers a cipher suite. Servers MUST NOT negotiate use of a DHE or ECDHE cipher suites unless the client supplies a supported NamedGroup.  If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert. (see mti-extensions) If the extension is provided, but no compatible group is offered, the server MUST NOT negotiate a cipher suite of the relevant type.  For instance, if a client supplies only ECDHE groups, the server MUST NOT negotiate finite field Diffie-Hellman.  If no acceptable group can be selected across all cipher suites, then the server MUST generate a fatal "handshake_failure" alert. Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension.  Clients receiving this extension MUST respond with an "unsupported_extension" alert and close the connection. </ins> The "extension_data" field of this extension contains a "NamedGroupList" value: of the following octets.  Note that the first two octets indicate the extension type (Supported Group Extension):  NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyShare message.  The server 6.3.2.3.  <ins> The "client_key_share" extension contains the client's cryptographic parameters for zero or more non-PSK key establishment methods (currently DHE or ECDHE). All clients MUST send a valid "client_key_share" extension when offering any DHE or ECDHE cipher suites.  Servers MUST NOT negotiate use of a DHE or ECDHE cipher suites unless the client supplies a (possibly empty) "client_key_share" extension.  If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert. (see mti-extensions) Servers MUST NOT send this extension.  TLS servers MUST support receiving this extension.  Clients receiving this extension MUST respond with an "unsupported_extension" alert and close the connection. [[OPEN ISSUE: Would it be better to omit it if it's empty?. </ins> https://github.com/tlswg/tls13-spec/issues/190]] %%% Key Exchange Messages struct { NamedGroup group; opaque multiple integer DH groups.  The shares for each ClientKeyShareOffer MUST by generated independently.  Clients MUST NOT offer multiple ClientKeyShareOffers for the same parameters.  It is explicitly  <ins> permitted to send an empty "client_key_share" extension as this is used to elicit the server's parameters if the client has no useful information. [[TODO: Recommendation about what the client offers.  Presumably which integer DH groups and which curves.]] </ins> 6.3.2.3.1. the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). <ins> All clients MUST send a valid "pre_shared_key" extension when offering any PSK cipher suites.  Servers MUST NOT negotiate use of a PSK cipher suite unless the client supplies a "pre_shared_key" extension.  If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert.  (see mti-extensions) </ins> The "extension_data" field of this extension contains a "PreSharedKeyExtension" value: An opaque label for the pre-shared key.  <ins> If no suitable identity is provided, the server MUST NOT negotiate a PSK cipher suite and MAY respond with an "unknown_psk_identity" alert message.  Sending this alert is OPTIONAL; servers MAY instead choose to send a "decrypt_error" alert to merely indicate an invalid PSK identity or instead negotiate use of a non-PSK cipher suite, if available. </ins> If the server selects a PSK cipher suite, it MUST send a PreSharedKeyExtension with the identity that it selected.  The client MUST verify that the server has selected one of the identities that the client supplied.  If any other identity is returned, the client  <ins> MUST generate a fatal "unknown_psk_identity" alert and close the connection. </ins> 6.3.2.5. Negotiated Groups ("supported_groups"; negotiated-groups)  <ins> Client Key Share ("client_key_share"; client-key-share) Pre-Shared Key Extension ("pre_shared_key"; pre-shared-key- extension) Server Name Indication ("server_name"; Section 3 of RFC6066) All implementations MUST send and use these extensions when offering applicable cipher suites: "signature_algorithms" is REQUIRED for certificate authenticated cipher suites "supported_groups" and "client_key_share" are REQUIRED for DHE or ECDHE cipher suites "pre_shared_key" is REQUIRED for PSK cipher suites When negotiating use of applicable cipher suites, endpoints MUST abort the connection with a "missing_extension" alert if the required extension was not provided.  Any endpoint that receives any invalid combination of cipher suites and extensions MAY abort the connection with a "missing_extension" alert, regardless of negotiated parameters. </ins>  <ins> Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it. Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension with a fatal "missing_extension" alert. </ins> 9.


certificate MUST come first in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed <del> independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates they may require. Note: Prior to TLS 1.3, "certificate_list" ordering was required to be strict, however some implementations already allowed for some flexibility.  For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version (with the exception of the sender's certificate).  Some servers are configured to send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly by clients capable of doing so. Although the chain MAY be ordered in a variety of ways, the peer's end-entity certificate MUST be the first element in the vector. </del>  The same message type and structure will be used for the client's response to a certificate request message.  Note that a client MAY

Remove self-signed, since the key point is that it's a trust anchor that was independently distributed. Note here that some trust anchors are signed, though that usually indicates a reason for it to be included, the signing might persist for longer than the actual need for it. Also the explanation had more words than it needed. n.b., I only loosely wrapped this stuff, if you want a proper wrapping of lines, name a preferred wrap column, because I couldn't work out what to do here.
The existing note is 722 char, the current PR is 700 char, and with the above suggestions it drops to 600 char. I think it's also a little easier to read, as a bit of that was redundant, especially after you reordered the sentences (which I agree flows in a more logical way now: what was different? -> why was it a problem? -> what should we do about it?).
NAME I sent you a PR to this PR for my suggested changes. URL
Server Name Indication could be encrypted to protect it from being inspected by passive attackers. There are some virtual-hosting type situations where hiding this information is considered desirable. If we can encrypt SNI, then it is probably trivial to encrypt other extensions. However, this complicates the handshake. A lot. It also complicates virtual-hosting scenarios. Rich summarizes the issues pretty well here: URL
Is this already ruled-out? How could the SNI be encrypted without an addition RTT? One could hash the SNI in the Client Hello which would at least help if the served host name is not publicly known (e.g. using a self-signed certificate).
It seems likely that there will eventually be an (optional?) extension that permits an encrypted "real" SNI, with some fake public SNI. But maybe that is not what you are asking.
NAME why was this closed?
Because we are not going to do anything about it in the base specification. I have concerns some about SNI encryption. First, I think it addresses a problem that is actually not that important for most. There are comparatively few sites on the web that have multiple properties served from a single host (or cluster). Certainly the biggest sites that received the most publicity for being under attack by the NSA -- Microsoft, Google, Yahoo, etc. -- are really a few to smallish number of services. And those companies have the wherewithal to deploy separate identities and IP addresses for their properties. Second, it potentially disadvantages a portion of the net: large CDN's and their customers. My employer, for example, serves thousands of sites on its TLS network, and encrypting SNI requires us to either have a single long-lived keypair for all customers, or require an extra RTT for clients to fetch an EDH key, perhaps still shared, but hopefully more secure. The latter is particularly off-putting since customers paying for a "faster, better" end-user experience are now at a disadvantage. Some in this community might not deploy TLS 1.3 to avoid the "retry penalty." This would be a shame. Third, we have not heard from the real potential community of consumers of this. I posit that they are mid-size sites with a "handful" of hosted properties. They are currently adequately served by virtual IP's, and even more so in the future by IPv6. And in terms of adversaries, does it matter which property within peacefire, for example, a user is contacting? A site under surveillance by a national-scale adversary will have everything scooped up anyway. Let me put some numbers on the previous points. We deliver content for around 10K domains, each with its own RSA keypair, out of 1500 locations. Without SNI, that means we need 15Million IP addresses, while being able to use SNI we only need one per location (region in our terminology). With SNI encryption we either need to share keys (bad for security, and perhaps not compliant with some regulations) or fragment IPs (bad for the web long-term). And that's just us. Add in all the CDNs, hosting companies, cloud providers... it's big. Do we know what people like AWS, Rackspace, IBM Cloud, etc., think about this? Fourth, it potentially "unlevels" the playing field. Organizations that have both a browser and servers of interest could, trivially, arrange to push out keys on a regular basis. I am not suggesting that anyone is planning on doing this, but I fear the temptation to do so in the name of "improving the user experience" will prove too great. In darker moments, I extrapolate the " browser list of CA's" story and imagine a future where Chrome talking to Google will be faster than IE talking to Bing, and Firefox will end up selling slots in its EDH store (sic) to attract revenue. Fifth, it introduces unknown security and trust implications in browsers. It took years to make "certificate stores" actually secure. And we are potentially opening up a new avenue of active attacks over the network while increasing the expectation that things are more secure. We are also increasing the client-side attack surface. Sixth, it adds an extra burden to servers. I think it also improves potential DoS attacks, since they could start at the first PDU exchange. Seventh, it ignores some of our own history. When HTTP/1.1 mandated the Host header, the virtual hosting industry was created. Until virtual IP's were well-known and SNI was widely adopted (I'm being charitable here), adoption of TLS among hosting providers had significant drag. If SNI is routing, then routing is plaintext and we are now going hide it without understanding the trade-offs. Finally, it is a lot of mechanism. As ekr said in London, "you have to do all this if you want to protect the SNI." It's not worth it. I think we're going too far, and we should come down on the side of simplicity, not for its own sake, but for security's sake. /r$ Principal Security Engineer Akamai Technology Cambridge, MA

certificate MUST come first in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed  <ins> independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it, however some implementations allowed some flexibility.  Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly.  For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first. </ins> The same message type and structure will be used for the client's response to a certificate request message.  Note that a client MAY


Structure of this message: %%% Authentication Messages struct { digitally-signed struct { opaque <del> handshake_hash[hash_length]; } } CertificateVerify; </del>  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>  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.

Missing semi-colon in the message definition. Also, the signature_algorithms of the client are what matter.

Structure of this message: %%% Authentication Messages struct { digitally-signed struct { opaque  <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  <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.


1.2 remain in this version.  Thanks to Mark Nottingham for doing the markdown translation.  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

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.

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


properties TLS does and does not provide and cannot safely rely on the latter. <del> Note in particular that the length of a record is not protected by encryption.  If this information is itself sensitive, application designers may wish to take steps (e.g., padding, cover traffic) to minimize information leakage. </del>  5.1. backward-compatibility. Implementations MUST NOT send zero-length fragments of Handshake or <del> Alert types.  Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. </del>  5.2.2. application_data(23); /* see fragment.type _/ ProtocolVersion record_version = { 3, 1 }; /_ TLS v1.x */ uint16 length; aead- ciphered struct { opaque content[TLSPlaintext.length]; ContentType <del> type; } fragment; } TLSCiphertext; </del>  The outer opaque_type field of a TLSCiphertext record is always The actual content type of the record.  The AEAD encrypted form of TLSPlaintext.fragment + <del> TLSPlaintext.type, where "+" denotes concatenation. </del>  The length of the per-record nonce (iv_length) is set to max(8 bytes, N_MIN) for the AEAD algorithm (see RFC5116 Section 4).  An AEAD length of the data. The AEAD output consists of the ciphertext output by the AEAD <del> encryption operation.  The length of the plaintext is one greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type. The length of aead_output will generally be larger than the plaintext, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of overhead could vary with different TLSPlaintext.length values.  Symbolically, </del>  In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext  6. TLS has three subprotocols that are used to allow peers to agree upon

This is a big improvement over the previous proposed methods, by the way. NAME I suggest filing a followup PR for your comments, as it looks like this has already merged.

properties TLS does and does not provide and cannot safely rely on the latter.  <ins> Note in particular that the length of a record or absence of traffic itself is not protected by encryption unless the sender uses the supplied padding mechanism - see record-padding for more details. </ins> 5.1. backward-compatibility. Implementations MUST NOT send zero-length fragments of Handshake or  <ins> Alert types, even if those fragments contain padding.  Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. </ins> 5.2.2. application_data(23); /* see fragment.type _/ ProtocolVersion record_version = { 3, 1 }; /_ TLS v1.x */ uint16 length; aead- ciphered struct { opaque content[TLSPlaintext.length]; ContentType  <ins> type; uint8 zeros[length_of_padding]; } fragment; } TLSCiphertext; </ins> The outer opaque_type field of a TLSCiphertext record is always The actual content type of the record. <ins> An arbitrary-length run of null bytes (uint8 with value 0) may appear in the cleartext after the type field.  This provides an opportunity for senders to pad any TLS record by a chosen amount as long as the total stays within record size limits.  See record- padding for more details. </ins> The AEAD encrypted form of TLSPlaintext.fragment +  <ins> TLSPlaintext.type + zeros, where "+" denotes concatenation. </ins> The length of the per-record nonce (iv_length) is set to max(8 bytes, N_MIN) for the AEAD algorithm (see RFC5116 Section 4).  An AEAD length of the data. The AEAD output consists of the ciphertext output by the AEAD  <ins> encryption operation.  The length of the plaintext is greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type and however much padding is supplied by the sender.  The length of aead_output will generally be larger than the plaintext, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext <ins> 5.2.3. All encrypted TLS records can be padded to inflate the size of the TLSCipherText.  This allows the sender to hide the size of the traffic from an observer. When generating a TLSCiphertext record, implementations MAY choose to pad.  An unpadded record is just a record with a padding length of zero.  Padding is a string of null bytes (uint8 with value 0) appended to the ContentType field before encryption.  Implementations MUST set the padding octets to all zeros before encrypting. Application Data records can be all padding if the sender desires. This permits generation of plausibly-sized cover traffic in contexts where the presence or absence of activity may be sensitive. Implementations MUST NOT send Handshake or Alert records that are all padding. The padding sent will be authenticated by the record protection mechanism.  Upon successful decryption of a TLSCiphertext.fragment, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero uint8.  This non-zero octet is the content type of the message. Implementations MUST limit their scanning to the cleartext returned from the AEAD decryption.  If a receiving implementation does not find a non-zero octet in the cleartext, it should treat the record as having an unexpected ContentType, sending an "unexpected_message" alert. The presence of padding does not change the overall record size limitations - the full fragment plaintext may not exceed 2^14 octets. Versions of TLS prior to 1.3 did not enable padding of any record at the TLS level.  The padding scheme introduced in TLS 1.3 was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types.  The design also enforces all-zero padding octets, which should avoid any risk of sending uninitialized memory as padding. Selecting a padding policy that suggests when and how much to pad is a complex topic, and is beyond the scope of this specification.  If the application layer protocol atop TLS permits padding, it may be preferable to pad application_data TLS records within the application layer.  Padding for encrypted handshake and alert TLS records must still be handled at the TLS layer, though.  Later documents may define padding selection algorithms, or define a padding policy request mechanism through TLS extensions or some other means. </ins> 6. TLS has three subprotocols that are used to allow peers to agree upon


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>  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  "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  "signature_algorithms". 6.3.12.

This completes the removal of SHA-1 for CertificateVerify. There's no reason to allow it there at all
LGTM

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  <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.


sha1_RESERVED(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm;  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.

This is stated to exist in the definition for "signature", however the value wasn't actually added to the enum. ( URL )

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.


Deprecate SHA-1 with signatures.  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>  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>  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>  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>

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

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,  <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  <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  <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.


were corrupted in the network). <del> This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode CBCATT.  It MUST NOT be sent by compliant implementations.  This alert is always fatal. </del> A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record with more than 2^14 bytes.  This alert is always fatal and should (except when messages were corrupted in the network). <del> This alert was used in previous versions of TLS.  TLS 1.3 does not include compression and TLS 1.3 implementations MUST NOT send this alert when in TLS 1.3 mode.  This alert is always fatal. </del> Reception of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available.  This alert is always fatal. <del> This alert was used in SSL 3.0 but not any version of TLS.  It MUST NOT be sent by compliant implementations.  This alert is always fatal. </del> A certificate was corrupt, contained signatures that did not verify correctly, etc. This alert is always fatal. <del> This alert was used in some earlier versions of TLS.  It MUST NOT be sent by compliant implementations.  This alert is always fatal. </del> The protocol version the peer has attempted to negotiate is recognized but not supported.  (For example, old protocol versions might be avoided for security reasons.)  This alert is always attempt from a client. (see RFC7507) This alert is always fatal. <del> This alert was used in previous versions of TLS.  TLS 1.3 does not include renegotiation and TLS 1.3 implementations MUST NOT send this alert when in TLS 1.3 mode.  This alert is always fatal. </del> Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version. This message is always fatal.  [[TODO: IANA Considerations.]] "supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), <del> sha1_RESERVED(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </del>  [[TODO: IANA considerations for new SignatureAlgorithm value]] This field indicates the hash algorithms which may be used.  The <del> values indicate support for unhashed data, MD5 RFC1321, SHA-1, 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. The use of MD5, SHA-1, and SHA-224 are deprecated.  The md5_RESERVED and sha224_RESERVED values MUST NOT be offered by any implementations.  The sha1_RESERVED value SHOULD NOT be offered, however clients willing to negotiate use of TLS 1.2 MAY offer support for SHA-1 for backwards compatibility with old servers. </del>  This field indicates the signature algorithm that may be used. <del> The values indicate anonymous signatures, RSASSA-PKCS1-v1_5, RFC3447, DSA DSS, ECDSA ECDSA, and RSASSA-PSS RFC3447 respectively.  Because all RSA signatures used in signed TLS handshake messages (see digital-signing), as opposed to those in certificates, are RSASSA-PSS, the "rsa" value refers solely to signatures which appear in certificates.  The use of DSA and anonymous is deprecated.  The anonymous_RESERVED value was used internally in prior versions of TLS and MUST NOT be offered or negotiated by any implementation of any TLS version.  The dsa_RESERVED value is deprecated as of TLS 1.3 and SHOULD NOT be offered or negotiated by any implementation. </del>  The semantics of this extension are somewhat complicated because the cipher suite indicates permissible signature algorithms but not hash in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF are reserved for private use. <del> Values within "obsolete_RESERVED" ranges were used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations.  The obsolete curves have various known/theoretical weaknesses or have had very little usage, in some cases only due to unintentional server configuration issues.  They are no longer considered appropriate for general use and should be assumed to be potentially unsafe.  The set of curves specified here is sufficient for interoperability with all currently deployed and properly configured TLS implementations. </del> Items in named_curve_list are ordered according to the client's preferences (most preferred choice first). Structure of this message: %%% Authentication Messages enum { rsa_sign(1), dss_sign_RESERVED(2), <del> rsa_fixed_dh(3), dss_fixed_dh_RESERVED(4), </del>  rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), <del> fortezza_dms_RESERVED(20), (255) } ClientCertificateType; </del>  A list of the types of certificate types that the client may signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms. <del> For historical reasons, the names of some client certificate types include the algorithm used to sign the certificate.  For example, in earlier versions of TLS, rsa_fixed_dh meant a certificate signed with RSA and containing a static DH key.  In TLS 1.2, this functionality has been obsoleted by the supported_signature_algorithms, and the certificate type no longer restricts the algorithm used to sign the certificate.  For example, if the server sends rsa_fixed_dh certificate type and {{sha256, ecdsa}, {sha1, rsa}} signature types, the client MAY reply with a certificate signed with ECDSA-SHA256. </del> New ClientCertificateType values are assigned by IANA as described in iana-considerations. <del> Note: Values listed as RESERVED MUST NOT be used.  They were used in SSL 3.0. </del> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.

Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.

were corrupted in the network).  A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record with more than 2^14 bytes.  This alert is always fatal and should (except when messages were corrupted in the network).  Reception of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available.  This alert is always fatal.  A certificate was corrupt, contained signatures that did not verify correctly, etc. This alert is always fatal.  The protocol version the peer has attempted to negotiate is recognized but not supported.  (For example, old protocol versions might be avoided for security reasons.)  This alert is always attempt from a client. (see RFC7507) This alert is always fatal.  Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version. This message is always fatal.  [[TODO: IANA Considerations.]] "supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1),  <ins> sha1, sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </ins> [[TODO: IANA considerations for new SignatureAlgorithm value]] This field indicates the hash algorithms which may be used.  The  <ins> values indicate support for unhashed data, SHA-1, 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.  Previous versions of TLS supported MD5 and SHA-1.  These algorithms are now deprecated and MUST NOT be offered by TLS 1.3 implementations.  SHA-1 SHOULD NOT be offered, however clients willing to negotiate use of TLS 1.2 MAY offer support for SHA-1 for backwards compatibility with old servers. </ins> This field indicates the signature algorithm that may be used.  <ins> The values indicate RSASSA-PKCS1-v1_5 RFC3447, DSA DSS, ECDSA ECDSA, and RSASSA-PSS RFC3447 respectively.  Because all RSA signatures used in signed TLS handshake messages (see digital- signing), as opposed to those in certificates, are RSASSA-PSS, the "rsa" value refers solely to signatures which appear in certificates.  The use of DSA and anonymous is deprecated. Previous versions of TLS supported DSA.  DSA is deprecated as of TLS 1.3 and SHOULD NOT be offered or negotiated by any implementation. </ins> The semantics of this extension are somewhat complicated because the cipher suite indicates permissible signature algorithms but not hash in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF are reserved for private use.  Items in named_curve_list are ordered according to the client's preferences (most preferred choice first). Structure of this message: %%% Authentication Messages enum { rsa_sign(1), dss_sign_RESERVED(2),  <ins> rsa_fixed_dh_RESERVED(3), dss_fixed_dh_RESERVED(4), </ins> rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),  <ins> fortezza_dms_RESERVED(20), ecdsa_sign(64), (255) } ClientCertificateType; </ins> A list of the types of certificate types that the client may signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms.  New ClientCertificateType values are assigned by IANA as described in iana-considerations.  Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.


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>  Meaning of this message:

…che).
Aside from the little nits and typo, the text itself looks good to me.

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  <ins> except PSK).  This message will always immediately follow the EncryptedExtensions message. </ins> Meaning of this message:


fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure.  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

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.

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.  5.2.3. All encrypted TLS records can be padded to inflate the size of the


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>  The TLS Handshake Protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order

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. =)

TLSPlaintext or TLSCiphertext structures, which are processed and transmitted as specified by the current active session state.  <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


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>  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.  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

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:

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  <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


%%% 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>  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

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.

%%% Authentication Messages struct { digitally-signed struct { opaque handshake_hash[hash_length]; }; } CertificateVerify;  <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


"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>  HashAlgorithm; [[TODO: IANA considerations for new SignatureAlgorithm value]]

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

"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1),  <ins> sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } </ins> HashAlgorithm; [[TODO: IANA considerations for new SignatureAlgorithm value]]


Structure of this message: <del> %%% Authentication Messages enum { rsa_sign(1), dss_sign_RESERVED(2), rsa_fixed_dh_RESERVED(3), dss_fixed_dh_RESERVED(4), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20), ecdsa_sign(64), (255) } ClientCertificateType; A list of the types of certificate types that the client may offer. </del>  A list of the hash/signature algorithm pairs that the server is <del> able to verify, listed in descending order of preference. </del>  A list of the distinguished names X501 of acceptable root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space.  If the certificate_authorities list is empty, then the client MAY <del> send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary. The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. certificate_types has been present in TLS since SSL 3.0, but was somewhat underspecified.  Much of its functionality is superseded by supported_signature_algorithms.  The following rules apply: Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms. The end-entity certificate provided by the client MUST contain a key that is compatible with certificate_types.  If the key is a signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms. New ClientCertificateType values are assigned by IANA as described in iana-considerations. </del>  Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication. The certificate type MUST be X.509v3 RFC5280, unless explicitly negotiated otherwise (e.g., RFC5081). <del> The end-entity certificate's public key (and associated restrictions) has to be compatible with the certificate types listed in CertificateRequest: </del> If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs. Note that this relaxes the constraints on certificate-signing algorithms found in prior versions of TLS.  Note that, as with the server certificate, there are certificates that use algorithms/algorithm combinations that cannot be currently used with TLS. registries and their allocation policies (unchanged from RFC4346) are listed below. <del> TLS ClientCertificateType Identifiers Registry: Future values in the range 0-63 (decimal) inclusive are assigned via Standards Action RFC2434.  Values in the range 64-223 (decimal) inclusive are assigned via Specification Required RFC2434.  Values from 224-255 (decimal) inclusive are reserved for Private Use RFC2434. </del> TLS Cipher Suite Registry: Future values with the first byte in the range 0-191 (decimal) inclusive are assigned via Standards Action RFC2434.  Values with the first byte in the range 192-254

This PR includes CertificateRequest changes discussed at the TLS WG Interim: Removes certificate_types, which are no longer needed. Adds client cert selection by certificate extension values. This helps make CertificateRequest more specific and eliminate the need for the confusing "Choose a certificate" UI.

Structure of this message:  <ins> %%% Authentication Messages opaque DistinguishedName<1..2^16-1>; </ins> A list of the hash/signature algorithm pairs that the server is  <ins> able to verify, listed in descending order of preference.  Any certificates provided by the client MUST be signed using a hash/ signature algorithm pair found in supported_signature_algorithms. </ins> A list of the distinguished names X501 of acceptable root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space.  If the certificate_authorities list is empty, then the client MAY  <ins> send any certificate that meets the rest of the selection criteria in the CertificateRequest, unless there is some external arrangement to the contrary. A list of certificate extension OIDs RFC5280 with their allowed values, represented in DER-encoded format.  Some certificate extension OIDs allow multiple values (e.g.  Extended Key Usage). If the server has included a non-empty certificate_extensions list, the client certificate MUST contain all of the specified extension OIDs that the client recognizes.  For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well).  However, the client MUST ignore and skip any unrecognized certificate extension OIDs.  If the client has ignored some of the required certificate extension OIDs, and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the session without client authentication, or terminate the session with a fatal unsupported_certificate alert.  PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types. Depending on the type, matching certificate extension values are not necessarily bitwise-equal.  It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs.  This document defines matching rules for two standard certificate extensions defined in RFC5280: The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension. The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension. The special anyExtendedKeyUsage OID MUST NOT be used in the request. Separate specifications may define matching rules for other certificate extensions. </ins> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication. The certificate type MUST be X.509v3 RFC5280, unless explicitly negotiated otherwise (e.g., RFC5081).  If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs. Note that this relaxes the constraints on certificate-signing algorithms found in prior versions of TLS. <ins> If the certificate_extensions list in the certificate request message was non-empty, the end-entity certificate MUST match the extension OIDs recognized by the client, as described in certificate-request. </ins> Note that, as with the server certificate, there are certificates that use algorithms/algorithm combinations that cannot be currently used with TLS. registries and their allocation policies (unchanged from RFC4346) are listed below.  TLS Cipher Suite Registry: Future values with the first byte in the range 0-191 (decimal) inclusive are assigned via Standards Action RFC2434.  Values with the first byte in the range 192-254


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>  All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the

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

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  <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


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>  Servers offer exactly one KeyShareEntry value, which corresponds to the key exchange used for the negotiated cipher suite.

Fix spacing to match other flow charts & fix one KeyShare->KeyShareEntry that was missed.

A single KeyShareEntry value for the negotiated cipher suite.  <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.


when it was able to find an acceptable set of algorithms and groups that are mutually supported, but the client's KeyShare did not contain an acceptable offer.  If it cannot find such a match, <del> it will respond with a "handshake_failure" alert. </del>  Structure of this message: [[OPEN ISSUE: Merge in DTLS Cookies?]] <del> The group which the client MUST use for its new ClientHello. </del>  <del> The "server_version", "cipher_suite" and "extensions" fields have the same meanings as their corresponding values in the ServerHello.  The </del>  server SHOULD send only the extensions necessary for the client to <del> generate a correct ClientHello pair. </del>  Upon receipt of a HelloRetryRequest, the client MUST first verify <del> that the "selected_group" field corresponds to a group which was </del>  provided in the "supported_groups" extension in the original <del> ClientHello.  It MUST then verify that the "selected_group" field does not correspond to a group which was provided in the "key_share" </del>  extension in the original ClientHello.  If either of these checks fails, then the client MUST abort the handshake with a fatal "handshake_failure" alert.  Clients SHOULD also abort with was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). <del> Otherwise, the client MUST send a ClientHello with a new KeyShare extension to the server.  The client MUST append a new KeyShareEntry list which is consistent with the "selected_group" field to the groups in its original KeyShare. </del>  Upon re-sending the ClientHello and receiving the server's ServerHello/KeyShare, the client MUST verify that the selected CipherSuite and NamedGroup match that supplied in the <del> HelloRetryRequest. </del>  [[OPEN ISSUE: https://github.com/tlswg/tls13-spec/issues/104]]

NAME You addressed the main ambiguity in URL . This fixes a few remaining issues. An itemized list: "handshakefailure" alert is fatal note it must be appended, not just "used", in the selectedgroup description (just using instead of appending creates a downgrade attack due to lack of authentication for this message, as discussed previously) clean up styling of variable names; the dominant style uses no quotes around variable names, but quotes around enum values (granted, this may not be the ideal style, but it is more or less consistently the case elsewhere in the document) note that the same rule as ServerHello applies: no extensions the client did not offer first update text to deal with possibility of omitted extension minor wording simplification specify error to use if "MUST" fails (could be a "SHOULD" error, here)
NAME Repushed commit with changes for comments. Changed description to not say used/amended, but rather describe what it actually represents directly: the group the server intends to negotiate and is requesting a retry for. (we don't need duplicated MUSTs here, and stating its actual meaning more explicitly is preferable) Changed text wrt selected group as suggested.
Rebased on top of PR (which still merges cleanly onto master, as of this moment; this does too) to avoid flip-flopping again on the omit vs. empty KeyShare for retry request.

when it was able to find an acceptable set of algorithms and groups that are mutually supported, but the client's KeyShare did not contain an acceptable offer.  If it cannot find such a match,  <ins> it will respond with a fatal "handshake_failure" alert. </ins> Structure of this message: [[OPEN ISSUE: Merge in DTLS Cookies?]]  <ins> The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </ins>  <ins> The server_version, cipher_suite, and extensions fields have the same meanings as their corresponding values in the ServerHello.  The </ins> server SHOULD send only the extensions necessary for the client to  <ins> generate a correct ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello. </ins> Upon receipt of a HelloRetryRequest, the client MUST first verify  <ins> that the selected_group field corresponds to a group which was </ins> provided in the "supported_groups" extension in the original  <ins> ClientHello.  It MUST then verify that the selected_group field does not correspond to a group which was provided in the "key_share" </ins> extension in the original ClientHello.  If either of these checks fails, then the client MUST abort the handshake with a fatal "handshake_failure" alert.  Clients SHOULD also abort with was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest).  <ins> Otherwise, the client MUST send a ClientHello with an updated KeyShare extension to the server.  The client MUST append a new KeyShareEntry for the group indicated in the selected_group field to the groups in its original KeyShare. </ins> Upon re-sending the ClientHello and receiving the server's ServerHello/KeyShare, the client MUST verify that the selected CipherSuite and NamedGroup match that supplied in the  <ins> HelloRetryRequest.  If either of these values differ, the client MUST abort the connection with a fatal "handshake_failure" alert. </ins> [[OPEN ISSUE: https://github.com/tlswg/tls13-spec/issues/104]]


between the ServerHello and the EncryptedExtensions encrypted- extensions message.  The ServerHello MUST only include extensions which are required to establish the cryptographic context.  6.3.1.3. to provide enough information to allow the server to decrypt the traffic without negotiation.  This is accomplished by having the client indicate the "cryptographic determining parameters" in its <del> ClientHello, which are necessary to decrypt the client's packets. This includes the following values: </del>  The cipher suite identifier. <del> If PSK is being used, the server's version of the PreSharedKey extension (indicating the PSK the client is using). </del>  <del> [[TODO: Are there other extensions we need?  I've gone over the list and I don't see any, but...]] [[TODO: This should be the same list as what you need for !EncryptedExtensions.  Consolidate this list.]] </del>  6.3.2.5.2. establish the cryptographic context.  The same extension types MUST NOT appear in both the ServerHello and EncryptedExtensions. If the same extension appears in both locations, the client MUST <del> rely only on the value in the EncryptedExtensions block.  [[OPEN ISSUE: Should we just produce a canonical list of what goes where and have it be an error to have it in the wrong place?  That seems simpler.  Perhaps have a whitelist of which extensions can be unencrypted and everything else MUST be encrypted.]] </del>  Structure of this message: allocation policy (unchanged from RFC4366) is listed below: TLS ExtensionType Registry: Future values are allocated via IETF <del> Consensus RFC2434.  IANA has updated this registry to include the "signature_algorithms" extension and its corresponding value (see hello-extensions). </del>  This document also uses two registries originally created in RFC4492. IANA [should update/has updated] it to reference this document.  The

Does it make sense to just have a tri-state column for TLS 1.3 on the extensions registry: "key" - key determining parameters "encrypted" - encrypted "forbidden" - not for use in TLS 1.3
"go" as in whether they are plaintext or go into the EncryptedExtensions block.

between the ServerHello and the EncryptedExtensions encrypted- extensions message.  The ServerHello MUST only include extensions which are required to establish the cryptographic context. <ins> 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. </ins> 6.3.1.3. to provide enough information to allow the server to decrypt the traffic without negotiation.  This is accomplished by having the client indicate the "cryptographic determining parameters" in its  <ins> ClientHello, which are necessary to decrypt the client's packets (i.e., those present in the ServerHello).  This includes the following values: </ins> The cipher suite identifier.  <ins> "key_share" if (EC)DHE is being used. </ins>  <ins> If PSK is being used, the server's version of the "pre_shared_key" (indicating the PSK the client is using). </ins> 6.3.2.5.2. establish the cryptographic context.  The same extension types MUST NOT appear in both the ServerHello and EncryptedExtensions. If the same extension appears in both locations, the client MUST  <ins> rely only on the value in the EncryptedExtensions block.  All server-sent extensions other than those explicitly listed in server-hello or designated in the IANA registry MUST only appear in EncryptedExtensions.  Extensions which are designated to appear in ServerHello MUST NOT appear in EncryptedExtensions.  Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </ins> Structure of this message: allocation policy (unchanged from RFC4366) is listed below: TLS ExtensionType Registry: Future values are allocated via IETF  <ins> Consensus RFC2434.  IANA [shall update/has updated] this registry to include the "key_share", "pre_shared_key", and "early_data" extensions as defined in this document.  IANA [shall update/has updated] this registry to include an "TLS 1.3" column with the following three values: "Clear", indicating that they shall be in the ServerHello "Encrypted", indicating that they shall be in the EncryptedExtensions block, and "Forbidden" indicating that they are not used in TLS 1.3.  This registry [shall be/has been] initially populated with the values in this document. </ins> This document also uses two registries originally created in RFC4492. IANA [should update/has updated] it to reference this document.  The