Subject: [TLS] PR for new negotiation syntax

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Aug 2016 08:30:22 -0700

Folks,

As promised, I've written a PR that describes the new negotiation
syntax we discussed in Berlin. I also have prototype implementation of
this in NSS and it's quite a bit cleaner than the previous negotiation
design. I think that others have found the same thing.

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

IMPORTANT: This new negotiation syntax allows for two modes that were
not previously available with TLS 1.3: PSK and PSK-(EC)DHE with
server-side signatures. This construction should be safe with
resumption-PSK (this is why we introduced the resumption_ctx design),
but as noted in Antoine's recent message [0], this is not safe with
non-resumption PSK with the all-zeroes resumption context that we now
use with external PSKs. I have an action item to fix that, so just
keep that in the back of your head as you review this PR.

Comments welcome.

-Ekr

[0] https://www.ietf.org/mail-archive/web/tls/current/msg20637.html

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 3 Aug 2016 21:15:27 +0300

> design. I think that others have found the same thing.

Yup, looks much cleaner.
 
> keep that in the back of your head as you review this PR.

The idea is to essentially use "resumption master secret" as PSK
and then to derive the two subkeys off that on handshake, right?

Also I noticed that now there is no indication on if the group
indication in HRR is valid or not (pure-PSK). Dirty hack would be
to grab some reserved value (FF01?) for "I don't need any more
groups" (which isn't the same as "no group"). Or perhaps one could
stick it into extension[1].

Also, now that there are signatures even with 0-RTT, one should recheck
the 0-RTT extension checking logic (the original logic is now invalid,
but I think conclusions[2] for free certificate case are still valid).

However, if the thing does not use free certificates (in which case
the logic should absolutely be specified, or one WILL get massive
interop problems!) the conclusions definitely are not valid..

[1] One design would be to move group to extensions, rename
'extensions' to something like 'problems'. Then require 'problems' to
be non-empty and require clients to abort if they see problem types
they don't recognize (but problem types don't need to be advertized).

[2] The original conclusions were that out of extensions, only
server_name and application_layer_protocol_negotiation matter.

-Ilari

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 4 Aug 2016 08:48:43 -0700

Hi Folks,

There was significant support for this approach in Berlin so if you have
concerns with this approach please post them to the list by Monday, August
8, 2016.

Thanks,

S&J

On Wed, Aug 3, 2016 at 8:30 AM, Eric Rescorla <[email-masked]> wrote:

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