Draft: draft-ietf-tls-tls13

Commentary: The document was pretty crisp about the version downgrade protections , but was less good about the changes to signature schemes . I have made a few changes to the description of signature_algorithms that should improve that . In particular , I have made it clear that the RSASSA - PSS codepoints are also defined for TLS 1.2 and that they can be used there . That means that TLS 3 implementations need to be prepared to accept PSS signatures . This also adds a section that points to the pieces that 1.2 implementations need to consider . 
 ( Well , I think , strictly speaking , we need only lock down HashAlgorithm . ) The SignatureScheme change assumes that we will never again allocate new values in the TLS 1.2 HashAlgorithm and SignatureAlgorithm ranges . I 'm not sure how to write that kind of IANA consideration or I 'd put together a PR . The end result should probably be something like s / Unassigned / Reserved for TLS 1.3 compatibility/. From TLS 1.3 onwards , all new signature algorithms that apply to TLS 1.2 must go through a backported  . ( If we 're not happy with that strong of a restriction , we could perhaps only burn HashAlgorithms 0x80 and up . Then TLS 1.3 SignatureSchemes live in the 0x8000 to 0xfdff range . Though 's PSS text already implies we 'll be backporting SignatureSchemes , so the division probably is n't necessary ? I dunno . I do n't really care either way . ) 
 Let 's just lock down HAshAlgorithm . Can you submit a PR ?
Paragraph (version B):
A version downgrade protection mechanism is described in server-
hello.
Paragraph (version B):
RSASSA-PSS signature schemes are defined in signature-algorithms.
Paragraph (version B):
An implementation of TLS 1.3 that also supports TLS 1.2 might need to
include changes to support these changes even when TLS 1.3 is not in
use.  See the referenced sections for more details.
Paragraph (version A):
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, the
length of the salt MUST be equal to the length of the digest
output.
Paragraph (version A):
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):
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, the
length of the salt MUST be equal to the length of the digest
output.  This codepoint is defined for use with TLS 1.2 as well as
TLS 1.3.  A server uses RSASSA-PSS signatures with RSA cipher
suites.
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.  A
server uses EdDSA signatures with ECDSA cipher suites.
Paragraph (version A):
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):
ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature
pairs.  However, the old semantics did not constrain the signing
curve.  If TLS 1.2 is negotiated, implementations MUST be prepared
to accept a signature that uses any curve that they advertised in
the "supported_groups" extension.
Paragraph (version B):
Implementations that advertise support for RSASSA-PSS (which is
mandatory in TLS 1.3), MUST be prepared to accept a signature
using that scheme even when TLS 1.2 is negotiated.