Subject: [TLS] Comments to draft tls13-18

From: "Guballa Jens (ETAS-PSC/ECS)" <[email-masked]>
Date: Thu, 15 Dec 2016 13:32:32 +0000

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

---

From: Dave Garrett <[email-masked]>
Date: Thu, 15 Dec 2016 19:09:31 -0500

>   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.

I've already updated this sentence for draft 19.
https://tlswg.github.io/tls13-spec/#backwards-compatibility-security-restrictions

Dave

---

From: "Guballa Jens (ETAS-PSC/ECS)" <[email-masked]>
Date: Fri, 16 Dec 2016 08:20:35 +0000

Hi,

> - 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".

[JG] Sorry, "master key" is wrong. I meant s/session key/master secret/ 

Thanks,
Jens

---

From: "Guballa Jens (ETAS-PSC/ECS)" <[email-masked]>
Date: Fri, 16 Dec 2016 08:26:56 +0000

> >   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.
>
[JG] Ah, Ok. This fixes the issue.

Thanks,
Jens

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Dec 2016 13:29:20 -0600

> My overall impression is that too less attention has been put on a clear and precise terminology.

Yes, that has not been a focus, and the document has evolved a lot over
time.

Several of the points you note already have pull requests outstanding
that fix them (in addition to the one Dave noted).  Someone will need to
put the time in to create a patch to resolve the others, but maybe it is
more efficient to wait until the other edits land in the main repo, first.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 17 Dec 2016 16:04:04 -0800

I've merged all the outstanding editorial PR. Jens, would you like to
propose changes via a PR?

-Ekr

On Fri, Dec 16, 2016 at 11:29 AM, Benjamin Kaduk <[email-masked]> wrote:

> Several of the points you note already have pull requests outstanding that
> fix them (in addition to the one Dave noted).  Someone will need to put the
> time in to create a patch to resolve the others, but maybe it is more
> efficient to wait until the other edits land in the main repo, first.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Guballa Jens (ETAS-PSC/ECS)" <[email-masked]>
Date: Mon, 19 Dec 2016 12:27:26 +0000

Yes, I will provide a PR.

Jens

Von: Eric Rescorla [mailto:[email-masked]]
Gesendet: Sonntag, 18. Dezember 2016 01:04
An: Benjamin Kaduk <[email-masked]>
Cc: Guballa Jens (ETAS-PSC/ECS) <[email-masked]>; <[email-masked]> 
<[email-masked]>
Betreff: Re: [TLS] Comments to draft tls13-18

I've merged all the outstanding editorial PR. Jens, would you like to propose 
changes via a PR?

-Ekr