RFC8446bis-09

[kazu-yamamoto]

https://author-tools.ietf.org/iddiff?url1=rfc8446&url2=draft-ietf-tls-rfc8446bis-09&difftype=--html

• Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by RFC8996.
• Removes ambiguity around which hash is used with PreSharedKeys and HelloRetryRequest.
• Require that clients ignore NewSessionTicket if they do not support resumption.
• Upgrade the requirement to initiate key update before exceeding key usage limits to MUST.
• Limit the number of permitted KeyUpdate messages.
• Restore text defining the level of "close_notify" to "warning". Clarify behavior around "user_canceled", requiring that "close_notify" be sent and that "user_canceled" should be ignored.
• Add a "general_error" generic alert.
• Corrected the lower bound on CertificateRequest.extensions to be 0 bytes. This was an error in the syntax as it is possible to send no extensions, which results in length 0.

[kazu-yamamoto]

4.1.2.

A server which receives a legacy_version value not equal to 0x0303 MUST abort the handshake with an "illegal_parameter" alert.

E.5.

The security of SSL 2.0 SSL2, SSL 3.0 RFC6101, TLS 1.0 RFC2246, reasons enumerated in RFC7568, and it MUST NOT be negotiated for and TLS 1.1 RFC4346 are considered insufficient for the reasons any reason. enumerated in RFC6176, RFC7568, and RFC8996 and they MUST NOT be negotiated for any reason.

[kazu-yamamoto]

The contents of the "extension_data" field are typically defined by an extension-specific structure defined in the TLS presentation language. Unless otherwise specified, trailing data is forbidden. That is, senders MUST NOT include data after the structure in the "extension_data" field. When processing an extension, receivers MUST abort the handshake with a "decode_error" alert if there is data left over after parsing the structure. This does not apply if the receiver does not implement or is configured to ignore an extension.

[kazu-yamamoto]

Transcript-Hash(Truncate(ClientHello1))

Where Truncate() removes the binders list from the ClientHello. Note that this hash will be computed using the hash associated with the PSK, as the client does not know which cipher suite the server will select.If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over:

   Transcript-Hash(ClientHello1,
                   HelloRetryRequest,
                   Truncate(ClientHello2))

The full ClientHello1/ClientHello2 is included in all other handshake hash computations. Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash" message, as described in Section 4.4.1. Note that the "message_hash" will be hashed with the negotiated function, which may or may match the hash associated with the PSK. This is consistent with how the transcript is calculated for the rest of the handshake.

[kazu-yamamoto]

• The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated otherwise (e.g., [RFC7250]).
• The end-entity certificate MUST allow the key to be used for signing with a signature scheme indicated in the client's "signature_algorithms" extension (see Section 4.2.3). That is, the digitalSignature bit MUST be set if the Key Usage extension is present, and the public key (with associated restrictions) MUST be compatible with some supported signature scheme.
• The "server_name" [RFC6066] and "certificate_authorities" extensions are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension when the server is identified by name.

[kazu-yamamoto]

Clients which receive a NewSessionTicket message but do not support resumption MUST silently ignore this message. Resumption MAY be done while the original connection is still open.

[kazu-yamamoto]

With a 128-bit key as in AES-128, rekeying 2^64 times has a high probability of key reuse within a given connection. Note that even if the key repeats, the IV is also independently generated, so the chance of a joint key/IV collision is much lower. In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch -- and hence the number of key updates -- to exceed 2^48-1. In order to allow this value to be changed later -- for instance for ciphers with more than 128-bit keys -- receiving implementations MUST NOT enforce this rule. If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits and SHOULD instead ignore the "update_requested" flag. This may result in an eventual need to terminate the connection when the limits in Section 5.5 are reached.

[kazu-yamamoto]

Implementations MUST either close the connection or do a key update as described in Section 4.6.3 prior to reaching these limits. Note that it is not possible to perform a KeyUpdate for early data and therefore implementations MUST not exceed the limits when sending early data. Receiving implementations SHOULD NOT enforce these limits, as future analyses may result in updated values.

[kazu-yamamoto]

general_error(117),

general_error: Sent to indicate an error condition in cases when either no more specific error is available or the senders wishes to conceal the specific error code. Implementations SHOULD use more specific errors when available.

[kazu-yamamoto]

close_notify: This alert notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert has been received MUST be ignored. This alert MUST be sent with AlertLevel=warning.

user_canceled: This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure. If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more appropriate. This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning. Receiving implementations SHOULD continue to read data from the peer until a "close_notify" is received, though they MAY log or otherwise record them.

[kazu-yamamoto]

• early_exporter_master_secret -> early_exporter_secret
• exporter_master_secret -> exporter_secret
• resumption_master_secret -> resumption_secret
• Master Secret -> Main Secret

Note: the key derivation labels use the string "master" even though the values are referred to as "main" secrets. This mismatch is a result of renaming the values while retaining compatibility.