Subject: [TLS] draft-ietf-tls-tls-13-17 posted

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Oct 2016 09:32:36 -0700

Folks,

I have just uploaded draft-ietf-tls-tls13-17.

The major change in this draft is the removal of the 0-RTT Finished
and resumption_context constructs and their replacement with the
psk_binder. This has a number of side effects:

- Binds in the original transcript into the resumed handshake
  whenever resumption-PSK is used.

- Provides proof of possession of the RMS by the client (subject
  to replay issues). I've moved the obfuscated_ticket_age field
  out of the early_data_indication so that it now provides the
  same limited anti-replay for non-0-RTT PSK.

- Removes the need for any early handshake encryption. This change,
  along with the dual key ladders we introduced in -16, also allowed
  us to simplify the traffic key expansion so we don't need explicit
  labels for each key (they are already used in Derive-Secret).

Other changes included:
- Tweaking the PSK key exchange modes a bit (and removing the
  inoperative ability to specify PSK auth modes, while leaving
  a hook to do it later).

- Cleaned up the cipher suite requirements for resumption and 0-RTT.
  You can resume/do PSK as long as the PSK KDF matches, but to do 0-RTT
  you need the whole cipher suite must match.

This revision resolves all the outstanding technical PRs [0] and all but
one of the non-parked technical issues (#144, whether we should remove the
redundant TLSCipherText.opaque_type and TLSCipherText.record_version
fields). We are pursuing measurements to resolve whether this will
be a compat problem but we don't have them yet.

As usual, comments welcome. We are already working on implementing
-17 in NSS/Firefox and should have it before Seoul.

-Ekr

Full Changelog
- Remove the 0-RTT Finished, resumption_context, and replace with a
  psk_binder field in the PSK itself (*)

- Restructure PSK key exchange negotiation modes (*)

- Add max_early_data_size field to TicketEarlyDataInfo (*)

- Add a 0-RTT exporter and change the transcript for the regular exporter
(*)

- Merge TicketExtensions and Extensions registry. Changes
  ticket_early_data_info code point (*)

- Replace Client.key_shares in response to HRR (*)

- Remove redundant labels for traffic key derivation (*)

- Harmonize requirements about cipher suite matching: for resumption you
  need to match KDF but for 0-RTT you need whole cipher suite. This
  allows PSKs to actually negotiate cipher suites. (*)

- Explicitly allow non-offered extensions in NewSessionTicket

- Explicitly allow predicting ClientFinished for NST

- Clarify conditions for allowing 0-RTT with PSK

[0] The two remaining outstanding PRs are:
#680: Forbid post-handshake authentication except when permitted by
      application profile. This is almost entirely a requirements-level
      change, though it would allow clients to send "unexpected_message"
      when receiving an unexpected CertificateRequest.

#612: TLS 1.3 -> TLS 2.0
      This has no change on the wire format.

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 21 Oct 2016 04:43:33 +0900

Hello,

It's great to see draft-17 being published. Thank you all for the effort.

Maybe the addition of extensions field to the Certificate message got
lost in the changelog?
https://github.com/tlswg/tls13-spec/pull/654

My understanding has been that it was a post-16 change and it changes
the wire protocol.

2016-10-21 1:32 GMT+09:00 Eric Rescorla <[email-masked]>:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Kazuho Oku

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Oct 2016 12:51:35 -0700

You're right. I just missed it. Added to the editor's copy.

Thanks,
-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 12:33:50 +0300

> I have just uploaded draft-ietf-tls-tls13-17.

Updated my own implementation from -16 to -17 (TODO: Add to
implementations page, it isn't any of the ones listed).

And since that implementation supports RFC7250 (for the server
certificate), here is my interpretation of it:

The certificate type is sent in extensions of EE certificate,
via the usual server_certificate_type extension (using the server-side
syntax from RFC7250).

Okay, the extension is after the certificate it attaches to (which is
just weird), but turns out this wasn't that bad to implement, due to
how the code happened to be laid out (it first sliced the certificate
message to extract the certificates and only afterwards processed
those).

... Interop tests with picotls failed:

- Picotls sends extension 13 (signature_algorithms) in ServerHello,
  which my implementation does not like[1].
- Picotls still seems to have the resumption_context mixed into
  hashes. I tought that got nuked when switching to "finished
  stuffing"? This causes wrong encryption keys to be derived,
  causing the handshake to blow up.

[1] Wasn't this ripped out in -17? The -17 draft seems to list that
extension as "clear", shouldn't it be "client" as the AFAIK the
server won't send it?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Oct 2016 04:39:59 -0700

> implementations page, it isn't any of the ones listed).

Please do.

We're working on ours so interop testing would be great.

> via the usual server_certificate_type extension (using the server-side

I think this probably should go in Encrypted Extensions.

>   which my implementation does not like[1].

You are correct.

>   causing the handshake to blow up.

It did.

> extension as "clear", shouldn't it be "client" as the AFAIK the

Thanks. That got missed in the update.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 17:00:57 +0300

> I think this probably should go in Encrypted Extensions.

It is definitely related to the certificate chain, and the spec
says such things should go to the first certificate slot (and indeed
the table about extensions says it goes to certificate extensions
block (but not which one).

The client_certificate_type (which I am not using) is listed to go to
EncryptedExtensions, which definitely looks wrong to me, being another
extension related to the certificate chain.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Oct 2016 08:00:33 -0700

On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara <[email-masked]>
wrote:

> It is definitely related to the certificate chain,

My argument would be that it doesn't belong in "individual certificates"
because it applies to certificates as a whole. It's not like it would be
legal to have a 7250 cert followed by an X.509 cert, one hopes

-Ekr

-Ekr

and the spec

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 18:06:09 +0300

> legal to have a 7250 cert followed by an X.509 cert, one hopes

Well, there can't be two server certificate "chains". But if there
could, I would expect the type to per-chain.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Oct 2016 08:14:50 -0700

> could, I would expect the type to per-chain.

Sorry, I'm not sure I am following.

What I am concerned about is the case where ServerCertificate =

[
   {
      Extensions : [ server_certificate_type = RawPublicKey],
      Certificate  : <some SPKI>
   } ,
   {
      Extensions : [],
      Certificate : <some X.509 cert>
   }
]

What is the other side supposed to do with that?

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 18:21:57 +0300

> What is the other side supposed to do with that?

Well, my implementation treats it the same as TLS 1.2 handshake with
server_certificate_type=RPK and a two certificates in the chain). Which
apparently means just ignoring the second certificate.

But if it had certificate type that could use multiple slots, there
could only be one chain type (server_certificate_type can only appear
once per chain, in the first slot).

-Ilari

---

From: Sean Turner <[email-masked]>
Date: Fri, 21 Oct 2016 11:38:15 -0400

> On Oct 21, 2016, at 07:39, Eric Rescorla <[email-masked]> wrote:
> 
> On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <[email-masked]> wrote:

Not sure how up to date this is but here’s a list of some implementations:

https://github.com/tlswg/tls13-spec/wiki/Implementations

spt

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 22 Oct 2016 06:58:57 +0900

>   causing the handshake to blow up.

Thank you very much for testing, and for reporting the issues you
found. Apparently I missed the changes when I made the adjustments for
draft-17.

I've pushed the fixes on to my git repository
(https://github.com/h2o/picotls) fixing the two issues. Hopefully with
them, picotls would be able to communicate with your implementation (I
think it might be better to go through my code with draft-17 in hand
to see if any other discordances exist, but that'll be in the next
week).

I am also looking forward to seeing your implementation on the Wiki.

-- 
Kazuho Oku