Draft: draft-ietf-tls-tls13

Commentary: This PR contains proposed specification text for the mailing list thread here : SignatureAlgorithm and HashAlgorithm are merged into a single u16 value . Fold signing curves into it as well . This is wire - compatible with TLS 1.2 , generalizes better to Ed25519 which combines all parameters into a single algorithm , and allows the server to report signature curve preferences to the client . Per discussion , there are only three ECDSA values , one per curve , so mismatching curve and hash is no longer allowed . They use the same values as the old TLS 1.2 ECDSA code points . ( If the WG decides differently here , that can be tweaked . ) Otherwise , I tried to keep SHOULD NOTs and  NOTs the same . MUST NOT values ( MD5 and SHA-224 ) are unallocated and remain at MUST NOT . DSA and SHA-1 remain allocated as they 're merely SHOULD NOT . Note : SHA-1 values are limited to rsapkcs1sha1 ( formerly {  , rsa } ) and  ( formerly {  , dsa } ) . TLS 1.2 's {  , ecdsa } does not have a corresponding TLS 1.3 value due to the curve / hash matching . ( Thus it implicitly falls in the unallocated pair MUST NOT bucket . ) Finally , with NamedGroups limited to ( EC)DH , this also removes the ' ecdh ' prefix on ecdhx25519 and ecdhx448 . X25519 and X448 already refer exclusively to Diffie - Hellman primitives and now there is no need to disambiguate between signing curves anyway .
Paragraph (version A):
The algorithm field specifies the algorithm used (see signature-
algorithms for the definition of this field).  Note that the
algorithm field was introduced in TLS 1.2, and is not in earlier
versions.  The signature is a digital signature using those
algorithms over the contents of the element.  The contents themselves
do not appear on the wire but are simply calculated.  The length of
the signature is specified by the signing algorithm and key.
Paragraph (version B):
The algorithm field specifies the algorithm used (see signature-
algorithms for the definition of this field).  The signature is a
digital signature using those algorithms over the contents of the
element.  The contents themselves do not appear on the wire but are
simply calculated.  The length of the signature is specified by the
signing algorithm and key.
Paragraph (version A):
In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PSS signature scheme defined in RFC3447 with MGF1.
The digest used in the mask generation function MUST be the same as
the digest which is being signed (i.e., what appears in
algorithm.signature).  The length of the salt MUST be equal to the
length of the digest output.  Note that previous versions of TLS used
RSASSA-PKCS1-v1_5, not RSASSA-PSS.
Paragraph (version A):
All ECDSA computations MUST be performed according to ANSI X9.62 X962
or its successors.  Data to be signed/verified is hashed, and the
result run directly through the ECDSA algorithm with no additional
hashing.  The SignatureAndHashAlgorithm parameter in the
DigitallySigned object indicates the digest algorithm which was used
in the signature.  Signature-only curves MUST NOT be used for ECDSA
unless otherwise noted.
Paragraph (version A):
All EdDSA computations MUST be performed according to I-D.irtf-cfrg-
eddsa or its successors.  Data to be signed/verified is passed as-is
to the EdDSA algorithm with no hashing.  The signature output is
placed as-is in the signature field.  The
SignatureAndHashAlgorithm.hash value MUST set to none(0).
Paragraph (version B):
The combined input is then fed into the corresponding signature
algorithm to produce the signature value on the wire.  See signature-
algorithms for algorithms defined in this specification.
Paragraph (version A):
The length of the structure, in bytes, would be equal to two bytes
for field1 and field2, plus two bytes for the signature and hash
algorithm, plus two bytes for the length of the signature, plus the
length of the output of the signing algorithm.  The length of the
signature is known because the algorithm and key used for the signing
are known prior to encoding or decoding this structure.
Paragraph (version B):
The length of the structure, in bytes, would be equal to two bytes
for field1 and field2, plus two bytes for the signature algorithm,
plus two bytes for the length of the signature, plus the length of
the output of the signing algorithm.  The length of the signature is
known because the algorithm and key used for the signing are known
prior to encoding or decoding this structure.
Paragraph (version A):
The client uses the "signature_algorithms" extension to indicate to
the server which signature/hash algorithm pairs may be used in
digital signatures.
Paragraph (version B):
The client uses the "signature_algorithms" extension to indicate to
the server which signature algorithms may be used in digital
signatures.
Paragraph (version A):
Each SignatureAndHashAlgorithm value lists a single hash/signature
pair that the client is willing to verify.  The values are indicated
in descending order of preference.
Paragraph (version A):
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, SHA-1, SHA-256, SHA-
384, and SHA-512 SHS, respectively.  The "none" value is provided
for signature algorithms which do not require hashing before
signing, such as EdDSA.  Previous versions of TLS supported MD5,
SHA-1, and SHA-224.  These algorithms are now deprecated.  MD5 and
SHA-224 MUST NOT be offered by TLS 1.3 implementations; SHA-1
SHOULD NOT be offered.  Clients MAY offer support for SHA-1 for
backwards compatibility, either with TLS 1.2 servers or for
servers that have certification paths with signatures based on
SHA-1.
Paragraph (version A):
This field indicates the signature algorithm that may be used.
The values indicate RSASSA-PKCS1-v1_5 RFC3447, DSA DSS, ECDSA
ECDSA, RSASSA-PSS RFC3447, and EdDSA I-D.irtf-cfrg-eddsa
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.
Paragraph (version A):
The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash
algorithms.  server-certificate-selection and key-share describe the
appropriate rules.
Paragraph (version A):
Clients offering support for SHA-1 for backwards compatibility MUST
do so by listing those hash/signature pairs as the lowest priority
(listed after all other pairs in the 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).
Paragraph (version A):
The signatures on certificates that are self-signed or certificates
that are trust anchors are not validated since they begin a
certification path (see RFC5280, Section 3.2).  A certificate that
begins a certification path MAY use a hash or signature algorithm
that is not advertised as being supported in the
"signature_algorithms" extension.
Paragraph (version A):
Note: TLS 1.3 servers might receive TLS 1.2 ClientHellos which do not
contain this extension.  If those servers are willing to negotiate
TLS 1.2, they MUST behave in accordance with the requirements of
RFC5246 when negotiating that version.
Paragraph (version A):
When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports, ordered from most
preferred to least preferred.
Paragraph (version A):
Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic_curves" and only contained elliptic curve groups.  See
RFC4492 and I-D.ietf-tls-negotiated-ff-dhe.
Paragraph (version B):
Each SignatureAlgorithm value lists a single signature algorithm that
the client is willing to verify.  The values are indicated in
descending order of preference.  Note that a signature algorithm
takes as input an arbitrary-length message, rather than a digest.
Algorithms which traditionally act on a digest should be defined in
TLS to first hash the input with a specified hash function and then
proceed as usual.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PKCS1-v1_5 RFC3447
with the corresponding hash algorithm as defined in SHS.  These
values refer solely to signatures which appear in certificates
(see server-certificate-selection) and are not defined for use in
signed TLS handshake messages (see digital-signing).
Paragraph (version B):
Indicates a signature algorithm using DSA DSS with the
corresponding hash algorithm as defined in SHS.  These values
refer solely to signatures which appear in certificates (see
server-certificate-selection) and are not defined for use in
signed TLS handshake messages (see digital-signing).
Paragraph (version B):
DSA is deprecated as of TLS 1.3.  These values SHOULD NOT be
offered or negotiated by any implementation.  It is believed that
the vast majority of implementations will not need to offer these
values in order to interoperate with lesser TLS versions.
Paragraph (version B):
Indicates a signature algorithm using ECDSA ECDSA, the
corresponding curve as defined in ANSI X9.62 X962 and FIPS 186-4
DSS, and the corresponding hash algorithm as defined in SHS.  The
signature is represented as a DER-encoded X690 ECDSA-Sig-Value
structure.
Paragraph (version B):
Indicates a signature algorithm using RSASSA-PSS RFC3447 with
MGF1.  The digest used in the mask generation function and the
digest being signed are both the corresponding hash algorithm as
defined in SHS.  When used in signed TLS handshake messages (see
digital-signing), the length of the salt MUST be equal to the
length of the digest output.
Paragraph (version B):
Indicates a signature algorithm using EdDSA as defined in I-
D.irtf-cfrg-eddsa or its successors.  Note that these correspond
to the "PureEdDSA" algorithms and not the "prehash" variants.
Paragraph (version B):
The semantics of this extension are somewhat complicated because the
cipher suite adds additional constraints on signature algorithms.
server-certificate-selection describes the appropriate rules.
Paragraph (version B):
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
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).
Paragraph (version B):
The signatures on certificates that are self-signed or certificates
that are trust anchors are not validated since they begin a
certification path (see RFC5280, Section 3.2).  A certificate that
begins a certification path MAY use a signature algorithm that is not
advertised as being supported in the "signature_algorithms"
extension.
Paragraph (version B):
TLS 1.2 ClientHellos may omit this extension.
Paragraph (version B):
In TLS 1.2, the extension contained hash/signature pairs.  The
pairs are encoded in two octets, so SignatureAlgorithm values have
been allocated to align with TLS 1.2's encoding.  Some legacy
pairs are left unallocated.  These algorithms are deprecated as of
TLS 1.3.  They MUST NOT be offered or negotiated by any
implementation.  In particular, MD5 SLOTH and SHA-224 MUST NOT be
used.
Paragraph (version B):
ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA hash/
signature pairs.  However, the old semantics did not constrain the
signing curve.
Paragraph (version B):
When sent by the client, the "supported_groups" extension indicates
the (EC)DHE groups which the client supports, ordered from most
preferred to least preferred.
Paragraph (version B):
Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic_curves" and only contained elliptic curve groups.  See
RFC4492 and I-D.ietf-tls-negotiated-ff-dhe.  This extension was also
used to negotiate ECDSA curves.  Signature algorithms are now
negotiated independently (see signature-algorithms).
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-4
DSS.  Values 0xFE00 through 0xFEFF are reserved for private use.
Paragraph (version A):
Indicates support of the corresponding ECDH functions X25519 and
X448.
Paragraph (version A):
Indicates support of the corresponding curve for signatures.
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.  Others are recommended in I-D.irtf-cfrg-curves.  Values
0xFE00 through 0xFEFF are reserved for private use.
Paragraph (version A):
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA or EdDSA key in its certificate,
and (ii) the ephemeral ECDH key in its "key_share" extension.  The
server must consider the supported groups in both cases.
Paragraph (version A):
The named group for the key being exchanged.  Finite Field Diffie-
Hellman DH parameters are described in ffdhe-param; Elliptic Curve
Diffie-Hellman parameters are described in ecdhe-param.
Signature-only curves, currently eddsa_ed25519 (31) and
eddsa_ed448 (32), MUST NOT be used for key exchange.
Paragraph (version B):
The named group for the key being exchanged.  Finite Field Diffie-
Hellman DH parameters are described in ffdhe-param; Elliptic Curve
Diffie-Hellman parameters are described in ecdhe-param.
Paragraph (version A):
For secp256r1, secp384r1 and secp521r1, this is the byte string
representation of an elliptic curve point following the conversion
routine in Section 4.3.6 of ANSI X9.62 X962.  For ecdh_x25519 and
ecdh_x448, this is raw opaque octet-string representation of point
(in the format those functions use), 32 octets for ecdh_x25519 and
56 octets for ecdh_x448.
Paragraph (version B):
For secp256r1, secp384r1 and secp521r1, this is the byte string
representation of an elliptic curve point following the conversion
routine in Section 4.3.6 of ANSI X9.62 X962.  For x25519 and x448,
this is raw opaque octet-string representation of point (in the
format those functions use), 32 octets for x25519 and 56 octets
for x448.
Paragraph (version A):
A list of the hash/signature algorithm pairs that the server is
able to verify, listed in descending order of preference.  Any
certificates provided by the client MUST be signed using a hash/
signature algorithm pair found in supported_signature_algorithms.
Paragraph (version B):
A list of the signature algorithms that the server is able to
verify, listed in descending order of preference.  Any
certificates provided by the client MUST be signed using a
signature algorithm found in supported_signature_algorithms.
Paragraph (version A):
The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the Key Usage extension is
present) with a signature scheme and hash algorithm pair indicated
in the client's "signature_algorithms" extension.
Paragraph (version A):
An ECDSA or EdDSA public key MUST use a curve and point format
supported by the client, as described in RFC4492.
Paragraph (version A):
All certificates provided by the server MUST be signed by a hash/
signature algorithm pair that appears in the "signature_algorithms"
extension provided by the client, if they are able to provide such a
chain (see signature-algorithms).  Certificates that are self-signed
or certificates that are expected to be trust anchors are not
validated as part of the chain and therefore MAY be signed with any
algorithm.
Paragraph (version A):
If the server cannot produce a certificate chain that is signed only
via the indicated supported pairs, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client.  This fallback chain MAY use the deprecated SHA-1 hash
algorithm only if the "signature_algorithms" extension provided by
the client permits it.  If the client cannot construct an acceptable
chain using the provided certificates and decides to abort the
handshake, then it MUST send an "unsupported_certificate" alert
message and close the connection.
Paragraph (version B):
The certificate MUST allow the key to be used for signing (i.e.,
the digitalSignature bit MUST be set if the Key Usage extension is
present) with a signature scheme indicated in the client's
"signature_algorithms" extension.
Paragraph (version B):
All certificates provided by the server MUST be signed by a signature
algorithm that appears in the "signature_algorithms" extension
provided by the client, if they are able to provide such a chain (see
signature-algorithms).  Certificates that are self-signed or
certificates that are expected to be trust anchors are not validated
as part of the chain and therefore MAY be signed with any algorithm.
Paragraph (version B):
If the server cannot produce a certificate chain that is signed only
via the indicated supported algorithms, then it SHOULD continue the
handshake by sending the client a certificate chain of its choice
that may include algorithms that are not known to be supported by the
client.  This fallback chain MAY use the deprecated SHA-1 hash
algorithm only if the "signature_algorithms" extension provided by
the client permits it.  If the client cannot construct an acceptable
chain using the provided certificates and decides to abort the
handshake, then it MUST send an "unsupported_certificate" alert
message and close the connection.
Paragraph (version A):
If sent by a server, the signature algorithm and hash algorithm
MUST be a pair offered in the client's "signature_algorithms"
extension unless no valid certificate chain can be produced
without unsupported algorithms (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 and EdDSA 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):
If sent by a client, the hash and signature algorithms used in the
signature MUST be one of those present in the
supported_signature_algorithms field of the CertificateRequest
message.
Paragraph (version A):
In addition, the hash and signature algorithms MUST be compatible
with the key in the sender's end-entity certificate.  RSA keys MAY
be used with any permitted hash algorithm, subject to restrictions
in the certificate, if any.  RSA signatures MUST be based on
RSASSA-PSS, regardless of whether RSASSA-PKCS-v1_5 appears in
"signature_algorithms".  SHA-1 MUST NOT be used in any signatures
in CertificateVerify, regardless of whether SHA-1 appears in
"signature_algorithms".
Paragraph (version B):
If sent by a server, the signature algorithm MUST be one offered
in the client's "signature_algorithms" extension unless no valid
certificate chain can be produced without unsupported algorithms
(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 and EdDSA values 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):
If sent by a client, the signature algorithm used in the signature
MUST be one of those present in the supported_signature_algorithms
field of the CertificateRequest message.