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 "unrelated" means here. If two session keys are derived from the same PSK without (EC)DHE, I would regard them as "related" (but both are still unique). - Page 111 (appendix D.1): "The PSK and resumption-PSK modes bootstrap from a long-term shared secret into a unique per-connection short-term session key." I do not understand the intention of this sentence. If a session key (master secret) is regarded as short-term, then consequently the resumption-PSK mode bootstrap from a short-term shared secret (master key from another session). - Section 8.1 and 8.2: I would replace "MTI" by "Mandatory to implement". - General: "out-of-band PSKs" vs. "handshake-derived PSKs": An "out-of-band PSK" (i.e., deployed out of band and a priori trusted) is not the same as a "handshake-derived PSK" which has been established via authenticated key agreement. In real-world deployments, these keys might be protected differently (e.g., an out-of-band PSK might be stored in an HSM, hardware security module). However, a handshake-derived shared secret might be located in RAM (i.e., it is not necessarily equally well suited for endpoint authentication as a long-term key). Best regards, Jens _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
