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

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

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