Draft: draft-ietf-tls-tls13

Commentary: For when the WG decides it is ok ... 
 I only see a couple spots left that need updating : 1 ) Update the version number to FIPS 186 - 4 in " Negotiated Groups " to match the updated DSS reference . 2 ) Update the version number to FIPS 180 - 4 in " Digital Signing " to match the current SHS reference , while you 're at it . 
 To cross - ref : this PR fixes issue and obsoletes issue 
 do we have consensus to merge this PR ? 
 Updated , rebased , merged conflicts with PSS patch and force pushed . 
 Merged 
 This should be closable now that DSA has been dropped from the spec . 
 TLS 1.2 currently supports a number of ciphersuites and mechanisms that are little - used or outdated . In particular SHA-1 , MD5 , RC4 , DSA with any modulus size , RSA with small moduli . Some of these will get chopped out as a result of other issues , but others will not . 
 Dependencies : SHA1 : PR MD5 : PR RC4 : PR DSA : PR weak RSA : PR Statuses : the pending PR drops SHA1 to SHOULD NOT MD5 is currently MUST NOT & PR also adds a MUST always error if seeing it RC4 is currently a MUST NOT DSA is pending decision & discussion on - list ( issue ; PR ) weak RSA is currently considered " not appropriate " with the following text : Merging the pending PRs listed as dependencies above should be sufficient to close this issue . 
 This is done
Paragraph (version A):
The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA RSA, DSA DSS, etc.).  This
authentication can be made optional, but is generally required for
at least one of the peers.
Paragraph (version B):
The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA RSA, ECDSA ECDSA, etc.).  This
authentication can be made optional, but is generally required for
at least one of the peers.
Paragraph (version A):
Note: In current terminology, DSA refers to the Digital Signature
Algorithm and DSS refers to the NIST standard.  In the original SSL
and TLS specs, "DSS" was used universally.  This document uses "DSA"
to refer to the algorithm, "DSS" to refer to the standard, and it
uses "DSS" in the code point definitions for historical continuity.
Paragraph (version A):
Note: Because not all signature algorithms and hash algorithms may be
accepted by an implementation (e.g., DSA with SHA-1, but not SHA-
256), algorithms here are listed in pairs.
Paragraph (version B):
Note: Because not all signature algorithms and hash algorithms may be
accepted by an implementation (e.g., ECDSA with SHA-256, but not SHA-
384), algorithms here are listed in pairs.
Paragraph (version A):
This field indicates the hash algorithms 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 use 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 B):
This field indicates the hash algorithms 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 use of MD5 and SHA-224 is deprecated.  The md5_RESERVED and
sha224_RESERVED values MUST NOT be offered or negotiated by any
implementation.
Paragraph (version A):
This field indicates the signature algorithm that may be used.
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 "anonymous" value is
meaningless in this context but used in server-key-share.  It MUST
NOT appear in this extension.
Paragraph (version B):
This field indicates the signature algorithm that may be used.
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.
Paragraph (version A):
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 named curve.  Note that
some curves are also recommended in ANSI X9.62 X962 and FIPS 186-4
DSS.  Values 0xFE00 through 0xFEFF are reserved for private use.
Paragraph (version A):
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 dss_fixed_dh certificate type and
{{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
with a certificate containing a static DH key, signed with RSA-
SHA1.
Paragraph (version B):
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.
Paragraph (version A):
The signature algorithm and hash algorithm MUST be a pair offered
in the client's "signature_algorithms" extension (see signature-
algorithms).  Note that there is a possibility for inconsistencies
here.  For instance, the client might offer DHE_DSS key exchange
but omit any DSA pairs from its "signature_algorithms" extension.
In order to negotiate correctly, the server MUST check any
candidate cipher suites against the "signature_algorithms"
extension before selecting them.  This is somewhat inelegant but
is a compromise designed to minimize changes to the original
cipher suite design.
Paragraph (version B):
The signature algorithm and hash algorithm MUST be a pair offered
in the client's "signature_algorithms" extension (see signature-
algorithms).  Note that there is a possibility for inconsistencies
here.  For instance, the client might offer ECDHE_ECDSA key
exchange but omit any ECDSA pairs from its "signature_algorithms"
extension.  In order to negotiate correctly, the server MUST check
any candidate cipher suites against the "signature_algorithms"
extension before selecting them.  This is somewhat inelegant but
is a compromise designed to minimize changes to the original
cipher suite design.
Paragraph (version A):
Note: Alerts and any other record types are not handshake messages
and are not included in the hash computations.  Also, HelloRequest
messages and the Finished message are omitted from handshake hashes.
The input to the client and server Finished messages may not be the
same because the server's Finished does not include the client's
Certificate and CertificateVerify message.
Paragraph (version B):
Note: Alerts and any other record types are not handshake messages
and are not included in the hash computations.  Also, HelloRequest
messages and the Finished message are omitted from handshake hashes.
Paragraph (version A):
Because DSA signatures do not contain any secure indication of
hash algorithm, there is a risk of hash substitution if multiple
hashes may be used with any key.  Currently, DSA DSS may only be
used with SHA-1.  Future revisions of DSS DSS-3 are expected to
allow the use of other digest algorithms with DSA, as well as
guidance as to which digest algorithms should be used with each
key size.  In addition, future revisions of RFC5280 may specify
mechanisms for certificates to indicate which digest algorithms
are to be used with DSA.