Draft: draft-ietf-tls-tls13

Commentary: This is a set of changes covering mailing list discussions about error alerts , certificate acceptance , SHA-1 deprecation , as well as including some recommendations about curves . There 's also quite a few other little fixes mixed in there , including some cleanups in RFC2119 language . The alerts list has been fully updated to include all standardized alerts ( PSK alert is needed for new PSK extension , in particular ) . This also adds RFC 5746 ( " renegotiation_info " info extension ) to the list of newly obsoleted RFCs , as renegotiation has already been removed completely thus making it no longer applicable as of this new TLS version . PR has the discussed change to certificate ordering requirements , however it is waiting on to assess consensus so I 'm not including it here . ( Edited to note : final commits from this PR have changed and parts have been broken off into other branches for other PRs ) 
 I pushed a new commit here to address your comments . I 've changed SHA1 to a SHOULD NOT except for backwards compatibility and explicit error cases for if the other two extensions are missing ( better explicit than implicit ) . 
 Yes , I was looking for the explicit description to send alerts in that case . I like those changes . : +1 : 
 Rebased and squashed a little bit . 
 Line 2011 in : it 's missing the information the client MUST abort the handshake with alert if the server sends a extension not advertised by client ( that does duplicate paragraph from line 2101 ) Line 2065 in : the client MUST abort the handshake with in case the selected values do n't match HelloRetryRequest . Line 2293 in : as the client may advertise the obsolete curves for backwards compatibility ( there are servers which will accept only those curves ) , the client MUST check if the server has n't selected one the backwards - compatible curves in TLS1.3 and abort the connection Line 3905 in : it 's missing that the server receiving SSLv2 type client hello with TLS1.3 version , MUST abort connection with alert I think we should be explicit in saying that the server MUST accept   message with version field higher than 3 , 4 but process it as if it was set to 3 , 4 . 
 Comments addressed in a new commit pushed here . The only two comments I did n't change something for are : I think " SHOULD " is acceptable for duplicate ClientKeyShareOffers checking , as that actually requires a little bit of effort for not much gain . Not strongly against a " MUST " though . I 'm leaving MD5 at a total ban and expectation of fatal error , because it 's garbage . I know the hash is meaningless in the context of trust anchors , but any exception to the rule of " if you see MD5 , kill it " is too much of an exception at this point . ( note that this does not apply to SHA1+MD5 in the context of old TLS versions , which is ugly but acceptable for backwards compatibility for now ) Edit : Latest commit has this plus yet more error cases . 
 Latest commit adds a couple new error alerts so that the current catchall of " handshake_failure " can be better broken up into individual specialized errors to make debugging and deciding what error message to show to users easier . 
 I 've split out all the purely editorial stuff into PR to reduce the size of this notably . This is based on top of that ( the first two commits are that PR ) . Most of the changesets are relatively narrow in focus , now . Each commit can be reviewed more or less separately before merging the whole PR . Having them all here means not having to handle nearly as many merge conflicts , because lots of these modify similar areas . 
 Rebased on top of master now that the editorial bits are merged . 
 Ok , this has now been pruned down to the first two commits , which covers just the MTI extensions and updating of the alerts registry ( just updating the documentation with the current standards ) . The other stuff is in another branch which I 'll submit as a new PR after this part is dealt with . GitHub forgot comments above , as they were on the old commit itself rather than technically on the PR ( an annoying habbit of GitHub , apparently ) . Still all here : I 've cut the allowed assumption of the TLS 1.2 SHA1 defaults when the extension is n't sent . The rest of the issues center on whether the TLC BCP is supposed to be the current standard set of expectations or not , as that 's pretty much all in line with that RFC . 
 There 's certainly not WG consensus that the UTA BCP applies to TLS as a whole , so this is not the time to merge those requirements in . Feel free to start a message on the mailing list , but I need to get -08 out so it 's going to have to wait 
 Understood . I 'll split them off , then . Should n't take long . 
 " Understood . I 'll split them off , then . Should n't take long . " Thanks . I 'm about to shut down for the night but I 'll deal with this tomorrow aM. 
 Ok , commit updated on this PR : cut out SNI & RI bits changed TLS 1.2 back - compat language to your suggestion lowered threshold for sending missingextension in response to no supportedgroups to only the case where it already causes a handshakefailure ( e.g. just use the new more precise error code when the server knows that the extension is missing ) " open issue " notes changed the DSA - ECDSA in the example expanded on truncated HMAC bit , though I did n't go as far as citing the specific paper on its security ( BCP does that ) ; as noted , it 's N / A for AEAD , anyway Took a little bit extra time to double - check that I got everything you and  wanted changed . ( it wanted an informative ref listing for the TLS 1.2 spec , which we apparently did n't have in the current version ) GitHub 's comment system is beginning to annoy me , btw . :| I have n't in the MTI bits for the clientkeyshare & preshared_key extensions that are in the larger branch , as you did n't review those yet , so just a note for now . This is also rebased onto current master and I made sure the second commit is documentation only ( the bulk of the changed lines are just shifting whitespace so they all fit ) . 
 There are a couple of places in the spec where it says client / server MUST not do x but does n't specify what happens if they do . Should we specify that behavior ? Some examples : s7.3.2 : Clients MUST NOT offer multiple ClientKeyShareOffers for the same parameters . s7.3.2.5 : There MUST NOT be more than one extension of the same type . s7.3.2.5.1 : signature ... It MUST NOT appear in this extension . and Servers MUST NOT send this extension . s7.3.2.5.3 : If the EarlyData extension is used , then clients MUST NOT send any messages other than the ClientHello in their initial flight . and Servers MUST NOT send the EarlyData extension . sA.4 : TLSNULLWITHNULLNULL is specified and is the initial state of a TLS connection during the first handshake on that channel , but MUST NOT be negotiated , as it provides no more protection than an unsecured connection . 
 Sounds like a good idea . I assume that the proper response is for the peer to send a fatal alert , but specifying exactly what alert is probably a good idea . 
 This is addressed in PR . 
 We should just require it . 
 I agree with that , it might go also with potentially deleting the SignatureAlgorithm from the new ciphersuites . By the way , should n't we consider also removing MD5 from HashAlgorithms even if it is used a lot ( I do n't know the numbers on that ... ) ? 
 PR mandates usage of this extension and also adds an explicit error expectation for MD5 ( it 's already listed as deprecated in the current draft ) . 
 This should be closable now .
Paragraph (version A):
Revise list of currently available AEAD cipher suites.
Paragraph (version B):
Update lists of available AEAD cipher suites and error alerts.
Paragraph (version B):
Sent by a server in response to an invalid connection retry
attempt from a client. (see RFC7507) This alert is always fatal.
Paragraph (version B):
Sent by servers when unable to obtain a certificate from a URL
provided by the client via the "client_certificate_url" extension
RFC6066.
Paragraph (version B):
Sent by servers when no server exists identified by the name
provided by the client via the "server_name" extension RFC6066.
Paragraph (version B):
Sent by clients when an invalid or unacceptable OCSP response is
provided by the server via the "status_request" extension RFC6066.
This alert is always fatal.
Paragraph (version B):
Sent by servers when a retreived object does not have the correct
hash provided by the client via the "client_certificate_url"
extension RFC6066.  This alert is always fatal.
Paragraph (version B):
Sent by servers when an unknown PSK identity is provided by the
client.  Sending this alert is OPTIONAL; servers MAY instead
choose to send a "decrypt_error" alert to merely indicate an
invalid PSK identity.
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 A):
If the negotiated key exchange algorithm is one of (DHE_RSA,
ECDHE_RSA), behave as if client had sent the value {sha1,rsa}.
Paragraph (version A):
If the negotiated key exchange algorithm is DHE_DSS, behave as if
the client had sent the value {sha1,dsa}.
Paragraph (version A):
If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as
if the client had sent value {sha1,ecdsa}.
Paragraph (version A):
Note: This extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in RFC6066
require servers to ignore extensions they do not understand.
Paragraph (version B):
All clients MUST send a valid "signature_algorithms" extension in
their ClientHello when offering certificate authenticated cipher
suites.  Servers receiving a TLS 1.3 ClientHello offering certificate
authenticated cipher suites without this extension MUST send a
"missing_extension" alert message and close the connection.
Paragraph (version B):
Note: TLS 1.3 servers MAY 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.
Paragraph (version A):
The client MUST supply a "supported_groups" extension containing at
least one group for each key exchange algorithm (currently DHE and
ECDHE) for which it offers a cipher suite.  If the client does not
supply a "supported_groups" extension with a compatible group, the
server MUST NOT negotiate a cipher suite of the relevant type.  For
instance, if a client supplies only ECDHE groups, the server MUST NOT
negotiate finite field Diffie-Hellman.  If no acceptable group can be
selected across all cipher suites, then the server MUST generate a
fatal "handshake_failure" alert.
Paragraph (version B):
The client MUST supply a "supported_groups" extension containing at
least one group for each key exchange algorithm (currently DHE and
ECDHE) for which it offers a cipher suite.  If the client does not
supply a "supported_groups" extension with a compatible group, the
server MUST NOT negotiate a cipher suite of the relevant type.  For
instance, if a client supplies only ECDHE groups, the server MUST NOT
negotiate finite field Diffie-Hellman.  If no acceptable group can be
selected across all cipher suites, then the server MUST generate a
fatal "handshake_failure" alert, or a "missing_extension" alert if no
extension was provided.
Paragraph (version A):
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a hash/
signature algorithm pair that appears in that extension.  Note that
this implies that a certificate containing a key for one signature
algorithm MAY be signed using a different signature algorithm (for
instance, an RSA key signed with a DSA key).
Paragraph (version B):
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 (see signature-algorithms).  [[OPEN
ISSUE: changing this is under consideration]] Note that this implies
that a certificate containing a key for one signature algorithm MAY
be signed using a different signature algorithm (for instance, an RSA
key signed with a ECDSA key).
Paragraph (version A):
If the client has offered the "signature_algorithms" extension,
the signature algorithm and hash algorithm MUST be a pair listed
in that extension.  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 "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):
All implementations MUST use the "signature_algorithms" extension
when offering and negotiating certificate authenticated cipher
suites.  All implementations MUST use the "supported_groups"
extension when offering and negotiating DHE or ECDHE cipher suites.