Subject: [TLS] Double-Checking after TLS 1.3 pre-RFC copy edits

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jul 2018 16:20:43 -0700

Dear TLS WG members.

I am doing my final copy-edits for the TLS 1.3 RFC and I noted one
technical point and two points I would like to edit for clarity but I
wanted more eyes on.

1. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.2

      If the client is attempting a PSK key
      establishment, it SHOULD advertise at least one cipher suite
      indicating a Hash associated with the PSK.

This seems like it would be better as a MUST. It's not a disaster
if we don't change it, but can anyone think of a reason it should
be a SHOULD?

2. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.4.2

The following block comes *after* the description of how to compute
ECDH for the NIST curves but before stuff about the CFRG curves.

   ECDH functions are used as follows:

   -  The public key to put into the KeyShareEntry.key_exchange
      structure is the result of applying the ECDH scalar multiplication
      function to the secret key of appropriate length (into scalar
      input) and the standard public basepoint (into u-coordinate point
      input).

   -  The ECDH shared secret is the result of applying the ECDH scalar
      multiplication function to the secret key (into scalar input) and
      the peer's public key (into u-coordinate point input).  The output
      is used raw, with no processing.

So it's not clear from the text which it applies to. I'm not the expert
here, but it seems like this is at least confusing in the context
of NIST curves, so perhaps we need to rescope it in to the CFRG
curves. This seems to be Ilari's text. Ilari?

3. The following text:

   Key derivation in TLS 1.3 uses the HKDF function defined in [RFC5869]
   and its two components, HKDF-Extract and HKDF-Expand.  The full
   rationale for the HKDF construction can be found in [Kraw10] and the
   rationale for the way it is used in TLS 1.3 in [KW16].  Throughout
   this document, each application of HKDF-Extract is followed by one or
   more invocations of HKDF-Expand.  This ordering should always be
   followed (including in future revisions of this document), in
   particular, one SHOULD NOT use an output of HKDF-Extract as an input
   to another application of HKDF-Extract without an HKDF-Expand in
   between.  Consecutive applications of HKDF-Expand are allowed as long
   as these are differentiated via the key and/or the labels.
   to another application of HKDF-Extract without an HKDF-Expand in

In context, this suggests that we're talking about:

   HKDF-Expand-Label(HKDF-Expand-Label())

but that's confusing because obviously those differ by key. I think we
are not trying to talk about this but rather about two HKDF-Expand-Labels
on related inputs. to that end, I changed it to:

   Multiple applications of HKDF-Expand to some of the same inputs are
   allowed as long as these are differentiated via the key and/or the
   labels.

We could also say that you can HKDF-Expand-Label() repeatedly as
above, but we don't actually do this, I believe, so no point in
saying it. Objections?

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 28 Jul 2018 10:48:51 +0300

> curves. This seems to be Ilari's text. Ilari?

There are basically three types of asymmetric key exchange TLS 1.3 can
currently use:

- Multiplicative Diffie-Hellman.
- Elliptic-Curve Diffie-Hellman with (x,y) point coordinates.
- "ECDH functions". 

And then the term "ECDH function" is seemingly not defined anywhere.
But that definition is certainly intended to encompass X25519 and
X448, being any function f from pair of octet strings to a
octet string plus octet string G, such that:

- f is easy to compute.
- f(a,f(b,G)) = f(b,f(a,G))
- It is hard to compute any f(a,f(b_i,G)) from f(a,G) and all f(b_i,G),
  for some index i, except with very small probability.

These condtions imply that one can construct Diffie-Hellman type key
exchange safe for multiple uses. For both X25519 and X448, one can find
such f and G. There are also other such function + base pairs (not
necressarily derived from elliptic curves).

And then there are key exchanges that are thought to be secure, but can
not be expressed in such framework, even with extra transforms. E.g. key
exchanges based on Key Encapsulation Mechanisms (which are important for
post-quantum, thus PQ would need a fourth type).

Looks like the text after it was considerably expanded from when that
text was originally introduced. It initially said "For X25519 and X448,
see [RFC7748]." (and in -11, it was a reference to the draft that
became RFC7748). Now it has considerably expanded text:

  For X25519 and X448, implementations SHOULD use the approach
  specified in [RFC7748] to calculate the Diffie-Hellman shared secret.
  Implementations MUST check whether the computed Diffie-Hellman shared
  secret is the all-zero value and abort if so, as described in
  Section 6 of [RFC7748].  If implementors use an alternative
  implementation of these elliptic curves, they SHOULD perform the
  additional checks specified in Section 7 of [RFC7748].

Might make sense to split the section and define the dangling term
somewhere?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 28 Jul 2018 06:41:09 -0700

> Might make sense to split the section and define the dangling term

Thanks. This helps.

The text here isn't totally generic, as it refers to scalar multiplication
and u-coordinate
point input. So, if we had some other ECDH-type thing that didn't have these
concepts, then we would have yet new text.

In the interest of the minimal change, I suggest:

"For X25519 and X448, the calculations are as follows"
...

"For these curves, implementations SHOULD use..."

How does that sound?

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 29 Jul 2018 18:10:17 +0300

> "For these curves, implementations SHOULD use..."

Yeah, passable. 

I do not think it is likely we need to add another DH function (due
to threat of QC making ((H)EC)DH go away), and even if we do, it is
just some extra text. The PQC asymmetric key exchanges will be KEMs,
which have pretty different behavior from existing things.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Jul 2018 15:28:48 -0700

Thanks!

---

From: Hubert Kario <[email-masked]>
Date: Mon, 30 Jul 2018 16:55:39 +0200

> if we don't change it, but can anyone think of a reason it should

It can be a MUST, but then we need to add a MUST for a server not to 
overinterpret lack of them (as in MUST NOT abort) - client may send a PSK 
associated with a hash in a ciphersuite that the server does not know

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic