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

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Oct 2016 16:43:58 +1100

Folks,

I have just posted draft-ietf-tls-tls13-18.

The only wire format change from -17 is that I removed the extra key
derivation stage computing resumption_psk from RMS. This was a
holdover from when we also had a resumption context. Now PSK for
connection N+1 = RMS from connection N. Thanks to Kazuho for
suggesting this simplification.

This draft also makes a number of minor editorial changes that
should make for easier reading.

The two remaining open technical issues I am aware of are both
requirements issues:

1. Can you resume with a different SNI than the one that the
   connection was initiated with [current answer is "no"]?

2. Do you need an application profile to do post-handshake
   client auth [current answer is "no"]?

There has been a bunch of discussion of these on the list but no
consensus declarations from the chairs. These are easy to change
in the draft once the chairs make the call.

As always, comments welcome.

-Ekr

P.S. NSS will be skipping draft-17 and going right to -18. This
should happen before Seoul.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 27 Oct 2016 14:27:09 +0900

Hi,

Thank you for posting draft-18, and thank you for the simplification of RMS.

I have finished implementing resumption and early-data in picotls. The
effort started just before draft-17 was published, so it would be fair
to say that my effort is solely based on the up-to-date specification.

I am happy to report that all I have found is one minor issue.

The issue I saw is discordance between PSKIdentity.identity and
NewSessionTicket.ticket.

In draft-18, PSKIdentity.identity is defined as <0..2^16-1>. OTOH
NewSessionTicket.ticket is <1..2^16-1>.

Is there any reason to only allow a zero-length identity for the former?

My understanding is that when resuming a session, the value of
NewSessionTicket.ticket is sent as PSKIdentity.identity. So to me, it
seems more natural if the permitted range of the two arrays were
equal.

Please forgive me for the fuss if the difference is intentional.

2016-10-26 14:43 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, 27 Oct 2016 16:30:09 +1100

> Please forgive me for the fuss if the difference is intentional.

Well, you could have an external PSK which I suppose might be zero length.

But I also wouldn't argue if we required this to be nonzero length.

-Ekr

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 27 Oct 2016 14:41:54 +0900

> But I also wouldn't argue if we required this to be nonzero length.

Thank you for the clarification.

Yes, having a zero-length external PSK makes sense.

And for the same reason, I would argue that having a zero-length
session identifier makes sense as well. For a client-server pair that
only talk to the other, a zero-length session identifier would work
well.

So if we are going to align the ranges of the two arrays, it might
make more sense to allow zero-length for both of them, instead of
disallowing it.

Please forgive me for the nit-pick.

-- 
Kazuho Oku

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Oct 2016 17:04:39 +1100

> make more sense to allow zero-length for both of them, instead of

I think that it would be better to have a minimum size here.  Those
applications that don't want to store a value for the ticket identity
can agree to send a one octet value or something like that.  I don't
think that we need a zero length value.

https://github.com/tlswg/tls13-spec/pull/744