Original text:
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.

Reviewer comments:
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.

Revised text:
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.