Subject: [TLS] draft-ietf-tls-tls13-21 posted

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Jul 2017 17:01:55 -0700

Hi folks,

I just published draft-21, which incorporates the discussions we've
been having about 0-RTT replay. This lead to two changes:

- Modifying the key derivation for PSKs so that each session ticket
  is associated with a distinct PSK.

- Adding a very extensive description of 0-RTT nti-replay and
  a SHOULD-level recommendation that servers use some anti-
  replay mechanism that doesn't allow replay within a given
  zone.

In addition, I have followed Richard Barnes's lead and added
key transition events to the state machine. This also clarified
that clients should send in-handshake alerts encrypted if they
can.

I wanted to call the WG's attention to one issue:

Currently the extension table says that server_certificate_type goes
in the Certificate message, whereas client_certificate_type does
not. My reasoning for the latter is that the extensions are attached
to individual certificate elements, so it was non-sensical to have a
situation where you might have cert A be X.509 and cert B be PGP.  I
think we should just change server_certificate_type to go in EE, and
then maybe in future if people want something cleverer they can add it
then. I didn't want to do this without WG discussion, but I think we
should and if people don't object I'll do it in a -22.

This version also addresses Kathleen's AD Review.

Other comments welcome.
-Ekr

[0] Note that this is a bit tricky when you are also streaming
Early Data.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Jul 2017 18:38:32 -0700

One more thing I wanted to note. The section about when you could receive
prior to Finished was a bit confused. I rewrote it as follows.

   Once a side has sent its Finished message and received and validated
   the Finished message from its peer, it may begin to send and receive
   application data over the connection.  There are two settings in
   which it is permitted to send data prior to receiving the peer's
   Finished:

   1.  Clients ending 0-RTT data as described in Section 4.2.9.

   2.  Servers MAY send data after sending their first flight, but
       because the handshake is not yet complete, they have no assurance
       of either the peer's identity or of it's liveness (i.e., the
       ClientHello might have been replayed).

This is not intended to be a normative change but just to capture the
current
state, so if people think I messed it up, or have proposed better wording,
please send PRs

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Jul 2017 11:57:45 +1000

>    1.  Clients ending 0-RTT data as described in Section 4.2.9.

Typo: ending.

Otherwise, this matches my understanding nicely.

---

From: Matt Caswell <[email-masked]>
Date: Tue, 4 Jul 2017 11:25:35 +0100

>   is associated with a distinct PSK.

Draft-21 says this about the ticket nonce:

          opaque ticket_nonce<1..255>;
...
   ticket_nonce  A unique per-ticket value.

Within what context is "uniqueness" required? I am assuming that
uniqueness within the context of a single TLS connection is all that
is needed?

The nonce can be anything between 1 and 255 bytes long. There is no
guidance on a suitable length, so I am assuming I can choose anything
I like as long as the uniqueness constraint is met. OpenSSL
(currently) only ever issues a single ticket per TLS connection so is
a single 0 byte sufficient?

Thanks

Matt

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 4 Jul 2017 13:50:50 +0300

> uniqueness within the context of a single TLS connection is all that

Yes, It has to be unique within a connection.

> a single 0 byte sufficient?

Yes, if you only have one ticket per connection, then any legal fixed
value is acceptable.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 4 Jul 2017 16:09:33 +0300

> should and if people don't object I'll do it in a -22.

The certificate type is certainly associated with the certificate
chain. However, it only makes sense for server certificate and there can
only be one such thing[1] and the data is small, so one could stick the
type in EE.

[1] Exported authenticators do not count, since the way those work is
rather different from usual TLS certificate authentication.

-Ilari

---

From: Matt Caswell <[email-masked]>
Date: Wed, 5 Jul 2017 09:40:13 +0100

> Yes, if you only have one ticket per connection, then any legal fixed

Thanks. Another slightly confusing thing about the way this is
currently specified:

The spec says:

   The PSK associated with the ticket is computed as:

       HKDF-Expand-Label(resumption_master_secret,
                        "resumption", ticket_nonce, Hash.length)

Where HKDF-Expand-Label is defined as:

       HKDF-Expand-Label(Secret, Label, HashValue, Length) =
            HKDF-Expand(Secret, HkdfLabel, Length)
...
        Note that in some cases a zero- length HashValue (indicated by
"") is passed to HKDF-Expand-Label.

Note that the third parameter here is explicitly expected to be either
a hash or "" (i.e. zero length). But in the ticket_nonce case this is
NOT a hash value. AFAICT this is the only time in the spec that
something other than a hash or "" is used for this parameter. I'm
assuming this is intentional and we are supposed to pass the nonce
through "as is" (i.e. there is no implicit requirement to hash it
first). Probably the definition of HKDF-Expand-Label needs to be
updated to allow for this usage.

Matt

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Jul 2017 03:35:00 -0700

> updated to allow for this usage.

Yes, that might not be a terrible idea. I'd also be open to replacing
the hashes of 0 with an n-byte length 0 string. It's a tiny paper
cut (and a wire format change), but would make things slightly simpler .

-Ekr

> Matt
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Jul 2017 07:14:58 +1000

> cut (and a wire format change), but would make things slightly simpler .

I think that would be best.  With the change to the transcript hash,
the context would then be:
1. a transcript hash (size = hash function output)
2. 0 (size = 0)
3. ticket nonce (size = 1..255)

Out of interest, why not permit 0 length ticket nonces for those of us
that don't issue multiple tickets?

I think that we should take the hit and make the change.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Jul 2017 14:16:47 -0700

> 3. ticket nonce (size = 1..255)

Yeah, I can do a PR for this.

> that don't issue multiple tickets?

That seems fine too.

-Ekr

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 06 Jul 2017 11:19:18 +0900 (JST)

So, HashValue is not a hash value anymore.
It should be "Value" or something.
The definitions would be:

       HKDF-Expand-Label(Secret, Label, *Value*, Length) =
            HKDF-Expand(Secret, HkdfLabel, Length)

       struct {
           uint16 length = *Value.length*;
           opaque label<7..255> = "tls13 " + Label;
           opaque hash_value<0..255> = *Value*;
       } HkdfLabel;

--Kazu

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Jul 2017 12:27:18 +1000

>            opaque hash_value<0..255> = *Value*;

Length is the size of the output, so you don't want to assign
Value.length to that field in the struct.  Also, you forgot to rename
hash_value in the struct.

The name "context" strikes me as a good choice here.  It shares a neat
parallel with the name used in exporters.  But I trust that ekr will
find a reasonable way of solving this.

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 06 Jul 2017 13:06:27 +0900 (JST)

> Value.length to that field in the struct.

Yes. I would remove the "length" field, too.

> Also, you forgot to rename hash_value in the struct.

You are right.

--Kazu

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Jul 2017 14:11:47 +1000

We need the length field so that calling the function with different
lengths results in different outputs.  Not that anyone should be doing
that, of course.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Jul 2017 21:18:03 -0700

> lengths results in different outputs.  Not that anyone should be doing

The reason for this is that an adversarial application might do so.

Say you have the secret in an HSM that has some sort of access control
capability
that doesn't let you exfiltrate keys. If the application can make a key
that is a prefix
of another key, then you can exhaustively search the keys by first
extracting a
one-byte key and searching that, etc. (IIRC Mike St Johns pointed out this
attack to me).
Now it's not a great an attack, but it is still sort of an attack.

-Ekr

---

From: Matt Caswell <[email-masked]>
Date: Fri, 7 Jul 2017 11:42:40 +0100

> cut (and a wire format change), but would make things slightly simpler .

I'm not entirely sure what you mean be the "hashes of 0". Are you
referring to the 0 length input passed to Derive-Secret in the various
Derive-Secret(., "derived", "") instances (and also for the
binder_key)?

Matt

---

From: Matt Caswell <[email-masked]>
Date: Fri, 7 Jul 2017 15:10:33 +0100

On 4 July 2017 at 01:01, Eric Rescorla <[email-masked]> wrote:
> been having about 0-RTT replay.

FYI, OpenSSL master branch is now draft-21 compliant.

Matt

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Jul 2017 11:40:22 -0500

> should and if people don't object I'll do it in a -22.

Seems worth doing.

[snip]

> [0] Note that this is a bit tricky when you are also streaming

I'm not sure what this footnote was supposed to refer to.

-Ben