Hi Ekr, Hi all, reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I noticed the TLS ExtensionType Registry on page 77 & page 78.
The "TLS 1.3" column has one of four values, namely
- "Client", indicating that the server shall not send them.
- "Clear", indicating that they shall be in the ServerHello.
- "Encrypted", indicating that they shall be
in the EncryptedExtensions block
- "No" indicating that they are not used in TLS 1.3.
The following values deserve a closer look:
+-------------------------------+-----------+-----------------------+
| Extension | Recommend | TLS 1.3 |
| | ed | |
+-------------------------------+-----------+-----------------------+
| server_name [RFC6066] | Yes | Encrypted |
| | | |
| max_fragment_length [RFC6066] | Yes | Encrypted |
| | | |
| key_share [[this document]] | Yes | Clear |
| | | |
| pre_shared_key [[this | Yes | Clear |
| document]] | | |
| | | |
| cookie [[this document]] | Yes | Encrypted/HelloRetryR |
| | | equest |
+-------------------------------+-----------+-----------------------+
The server_name extension is sent in the initial ClientHello and will
not be encrypted since it will be used to select the right server in a
hosting environment.
The max_fragment_length extension is sent in the initial ClientHello but
is not as essential as the server_name extension. Still, in most cases
there is no security context established at the time of sending the
ClientHello (at least not in the full handshake when ECDHE is used).
The key_share & the pre_shared_key extension is sent in clear in the
ClientHello and in the ServerHello.
The cookie is not sent encrypted in the HelloRetryRequest since the
HelloRetryRequest is sent when the client has not provided a suitable
"key_share" value. The DoS protection feature used in the
HelloRetryRequest is most likely useful only in context of an unreliable
transport protocol. If you want DoS protection then the server should
not store per-session state, which establishing security context would
require.
I believe the definition of 'clear' should be changed to:
"Clear", indicating that they shall be sent in clear
in the ClientHello and in the ServerHello.
I fear that the use of extension in the encrypted block may be dependent
on where they can first be used and also in what handshake variant. It
is also a question whether it makes sense to send an extension encrypted
in the ServerHello when it first appeared in clear in the ClientHello.
I wonder whether the "TLS 1.3" column in this table could actually be
simplified to only provide information about extensions that can be used
in TLS 1.3. Whether something is sent in clear, encrypted or only be the
client is something that should be described in the protocol
specification itself.
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
