Draft: draft-ietf-tls-tls13

Commentary: Not sure if the deprecation cutoff will be at 224 bits ( ~112 bit security level ) or 255 bits ( ~128 bit security level ) yet , so I 've just done the former for now . This drops the old curves under 224 bits , updates the extension example bytes , and deprecates MD5 . 
 As noted on - list , SHA1 ca n't be as easily dealt with here , so that 'll be a topic for a separate changeset . 
 Here 's a PR for this : Question : Are we dropping all curves < 224 bits or < 255 bits ? ( was consensus ever called on this specific number ? ) 
 There was not a specific WG consensus call on this point . I hope we do n't need one and that we should keep the curves in that are used and trim the ones that are n't . 
 Good . In that case , I 'll slash everything other than secp256r1 ( prime256v1 / NIST P-256 ) , secp384r1 ( NIST P-384 ) , secp521r1 ( NIST P-521 ) , and sect571r1 ( NIST B-571 ) . ( plus , of course , new CFRG curves yet to be ) PR updated . 
 Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures , can we drop that too while we 're at it ? ( not an exaggeration ; the scan cited in the last comment shows none ) 
 I would drop it . spt On Jun 17 , 2015 , at 20:09 ,   wrote : 
 OK . PR updated . 
 This can be closed now that PR has been merged .
Paragraph (version A):
draft-07 - Integration of semi-ephemeral DH proposal.
Paragraph (version B):
Remove support for weak and lesser used named curves.
Paragraph (version B):
Remove support for MD5 and SHA-224 hashes with signatures.
Paragraph (version B):
Integration of semi-ephemeral DH proposal.
Paragraph (version A):
This field indicates the hash algorithm which may be used.  The
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.
Paragraph (version B):
This field indicates the hash algorithm which may be used.  The
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 usage of MD5 and SHA-224 are deprecated.  The md5_RESERVED and
sha224_RESERVED values MUST NOT be offered or negotiated by any
implementation.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
Indicates support of the corresponding named curve.  Note that
some curves are also recommended in ANSI X9.62 X962 and FIPS 186-2
DSS.  Values 0xFE00 through 0xFEFF are reserved for private use.
Paragraph (version B):
Indicates support of the corresponding finite field group, defined
in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF
are reserved for private use.
Paragraph (version B):
Values within "obsolete_RESERVED" ranges were used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations.