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

Discussion:
Remove support for MD5 and SHA-224 hashes with signatures. <del> Revise list of currently available AEAD cipher suites. </del> <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. <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> <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 <del> fatal "handshake_failure" alert. </del> <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. <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> <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. <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> <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