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

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