Hi all,
I had a closer look at the TLS1.3-18-draft, and I would like to provide some
comments.
My overall impression is that too less attention has been put on a clear and
precise terminology.
- Throughout the draft the term "connection" refers to a TLS connection, but in
section 1.1 "connection" it is defined as a transport layer connection.
I would prefer a definition similar as provided by RFC 5246.
- Use of inconsistent terms for what a handshake produces:
At section 1.1: "handshake: An initial negotiation between client and server
that
establishes the *parameters of their transactions*."
-> Note, the term transaction is not used anywhere else in the draft
At page 13 (section 2): "The cryptographic *parameters of the session state*
are produced by the
TLS handshake protocol, ..."
At page 15: "The server processes the ClientHello and determines the
appropriate
cryptographic *parameters for the connection*. It then responds with
its own ServerHello, which indicates the negotiated connection
parameters."
At page 17 (section 2.2): "The client can then use that
PSK identity in future handshakes to negotiate use of the PSK. If
the server accepts it, then the *security context* of the new
connection is tied to the original connection."
At page 27 (section 4.1): "The key exchange messages are used to exchange
*security capabilities*
between the client and server and to establish the traffic keys used
to protect the handshake and data.
At page 75 (section 7.1): "The TLS handshake establishes one or more *input
secrets* which are
combined to create the actual *working keying material*, as detailed
below."
- The terms "working keys", "traffic keys" are not clearly defined and used
inconsistently, IMO.
"Traffic key" seems to refer to 0-RTT-keys, handshake keys and application
keys in most parts of the draft, on the other hand on page 78 (section 7.2):
"Once the handshake is complete, it is possible for either side to
update its sending *traffic keys* using the KeyUpdate handshake message
defined in Section 4.5.3."
-> Here "traffic key" seems to refer to application keys only.
I would prefer a clear definition of those key related terms in section 1.1.
- Page 16 (section 2):
"CertificateVerify: a signature over the entire handshake using the
public key in the Certificate message."
IMO, "entire handshake" would include the "Finished" from both sides, which I
believe is not intended.
Also, from the text one could think that the public key is used to generate
the CertificateVerify.
Proposal: "...using the public key in the Certificate message at the
receiving side for the verification of the signature."
- Page 17 (section 2.2): "The client can then use that
PSK identity in future handshakes to negotiate use of the PSK. If
the server accepts it, then the security context of the new
connection is tied to the original connection."
What does "is *tied* to" mean?
- Page 26 (section 4): "Handshake messages are supplied to the TLS record layer,
where they are encapsulated within one or more TLSPlaintext or
TLSCiphertext structures, which are processed and transmitted as
specified by the current active session state."
The TLS record layer has no view on the session state, IMO. Therefore I think
"as specified by the current active connection state" or "...by the current
traffic keys" makes more sense.
- Page 44 (section 4.2.6): "External
tickets SHOULD use an obfuscated_ticket_age of 0; servers MUST
ignore this value for external tickets."
I would avoid the term "external ticket", I think it is more confusing than
it helps.
Proposal: "For PSKs provisioned out of band, obfuscated_ticket_age SHOULD be
set to 0 by the client; servers MUST ignore this value for those PSKs."
- Section 4.4.2. Certificate Verify
There is no procedure defined for the receiver, I would expect that the
received MUST verify this message.
I would also prefer to have the procedure specified in case the verification
fails (also valid for the Finished message).
- Page 108 (appendix C.4): "If an implementation negotiates use of TLS 1.2,
then negotiation of
cipher suites also supported by TLS 1.3 SHOULD be preferred, if
available."
TLS cipher suites for TLS1.3 and TLS1.2 are disjunctive, in my understanding.
Therefore I think this sentence does not make any sense.
Unfortunately the semantic of "cipher suite" has been changed from TLS1.2 to
TLS1.3, thus there are different definitions of this term for both TLS versions.
- Page 110 (appendix D.1): I am not quite sure if the term "session key" is
needed at all. IMO, it is just a synonym for "master secret".
My proposal is to replace "session key" by "master key" throughout the
complete document.
- Page 110 (appendix D.1): "Uniqueness of the session key: Any two distinct
handshakes should
produce distinct, unrelated session keys."
I am not sure what
