Original text:
cipher suite adds additional constraints on signature algorithms. server-certificate-selection describes the appropriate rules. <del> rsa_pkcs1_sha1 and dsa_sha1 SHOULD NOT be offered.  Clients offering these values for backwards compatibility MUST list them as the lowest priority (listed after all other algorithms in the </del>  supported_signature_algorithms vector).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). key in the sender's end-entity certificate.  RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA- PKCS1-v1_5 algorithms appear in "signature_algorithms".  SHA-1 <del> MUST NOT be used in any signatures in CertificateVerify.  (Note that rsa_pkcs1_sha1 and dsa_sha1, the only defined SHA-1 signature algorithms, are undefined for CertificateVerify signatures.) </del>  Note: When used with non-certificate-based handshakes (e.g., PSK), the client's signature does not cover the server's certificate

Reviewer comments:
I'm going to see about getting rid of it anyway, but I think, for the spec, this is probably the better text, as sad as it makes me. The revised signature algorithm mechanism left the {sha1, ecdsa} SignatureAndHashAlgorithm without a corresponding SignatureScheme defined at all. SHA-1 does not have a corresponding curve, so defining it alongside ecdsap256sha256 and friends was a nuisance. But omitting it, combined with other text, implicitly means it "MUST NOT be offered or negotiated by any implementation". Clients (ideally) send only one ClientHello, so this implies a constraint on TLS 1.2 as well. SHA-1 needs to go, but I think I was a tad overzealous here. I wouldn't be surprised {sha1, ecdsa} can be removed from TLS 1.2 right now. Certainly it will be much much easier to remove than {sha1, rsa}. But this is probably better a SHOULD NOT rather than a MUST NOT. We wouldn't like to discover after the fact that a MUST NOT in TLS 1.3 is untenable due to some ecosystem problem. Notably, old versions of some popular server software ignore signature algorithms and only sign SHA-1. This mostly affects RSA since ECDSA isn't that common, but any such ECDSA deployments would be affected. This is also a little odd for servers as TLS 1.2 says missing sigalgs means the client is assumed to support {sha1, X}. (Although, strictly speaking, the spec does not say the server must do anything useful with that advertisement.) In contrast, dsasha1 is already not offered by many major browsers but is merely a SHOULD NOT. Define ecdsasha1RESERVED as a companion to dsa*RESERVED to bring it out of the implicit MUST NOT. Then include it in the SHOULD NOT lists alongside rsapkcs1sha1 and dsasha1.

Revised text:
cipher suite adds additional constraints on signature algorithms. server-certificate-selection describes the appropriate rules.  <ins> rsa_pkcs1_sha1, dsa_sha1, and ecdsa_sha1 SHOULD NOT be offered. Clients offering these values for backwards compatibility MUST list them as the lowest priority (listed after all other algorithms in the </ins> supported_signature_algorithms vector).  TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see server-certificate-selection). key in the sender's end-entity certificate.  RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA- PKCS1-v1_5 algorithms appear in "signature_algorithms".  SHA-1  <ins> MUST NOT be used in any signatures in CertificateVerify.  All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures. </ins> Note: When used with non-certificate-based handshakes (e.g., PSK), the client's signature does not cover the server's certificate