Draft: draft-ietf-tls-tls13

Commentary: Note : unRESERVEDing SHA-1 and DSA is intentional . The point is that that things which are RESERVED are totally forbidden . Because you can offer SHA-1 , we need the code point . If we decide to make DSA MUSTNOT , then I 'll mark it reserved and update the text . 
 On Saturday , October 03 , 2015 04:42:44 pm ekr wrote : Agreed . Using the " RESERVED " notation before was a bit iffy and with this new refactoring it has to be changed now . Just need to make sure it 's mentioned explicitly that it 's restricted .
Paragraph (version A):
This alert was used in some earlier versions of TLS, and may have
permitted certain attacks against the CBC mode CBCATT.  It MUST
NOT be sent by compliant implementations.  This alert is always
fatal.
Paragraph (version A):
This alert was used in previous versions of TLS.  TLS 1.3 does not
include compression and TLS 1.3 implementations MUST NOT send this
alert when in TLS 1.3 mode.  This alert is always fatal.
Paragraph (version A):
This alert was used in SSL 3.0 but not any version of TLS.  It
MUST NOT be sent by compliant implementations.  This alert is
always fatal.
Paragraph (version A):
This alert was used in some earlier versions of TLS.  It MUST NOT
be sent by compliant implementations.  This alert is always fatal.
Paragraph (version A):
This alert was used in previous versions of TLS.  TLS 1.3 does not
include renegotiation and TLS 1.3 implementations MUST NOT send
this alert when in TLS 1.3 mode.  This alert is always fatal.
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, SHA-1, and SHA-224 are deprecated.  The
md5_RESERVED and sha224_RESERVED values MUST NOT be offered by any
implementations.  The sha1_RESERVED value SHOULD NOT be offered,
however clients willing to negotiate use of TLS 1.2 MAY offer
support for SHA-1 for backwards compatibility with old servers.
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 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 B):
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 future extensibility, in case of a signature algorithm which
does not require hashing before signing.  Previous versions of TLS
supported MD5 and SHA-1.  These algorithms are now deprecated and
MUST NOT be offered by TLS 1.3 implementations.  SHA-1 SHOULD NOT
be offered, however clients willing to negotiate use of TLS 1.2
MAY offer support for SHA-1 for backwards compatibility with old
servers.
Paragraph (version B):
This field indicates the signature algorithm that may be used.
The values indicate 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.
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):
Values within "obsolete_RESERVED" ranges were used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations.  The obsolete curves have various known/theoretical
weaknesses or have had very little usage, in some cases only due to
unintentional server configuration issues.  They are no longer
considered appropriate for general use and should be assumed to be
potentially unsafe.  The set of curves specified here is sufficient
for interoperability with all currently deployed and properly
configured TLS implementations.
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 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):
Note: Values listed as RESERVED MUST NOT be used.  They were used in
SSL 3.0.