Subject: Re: [TLS] TLS1.3 status/expectations

From: Watson Ladd <[email-masked]>
Date: Tue, 1 Mar 2016 18:42:54 -0800

On Mon, Feb 29, 2016 at 6:45 AM, Sean Turner <[email-masked]> wrote:
> At the TRON workshop [0], we (Joe and Sean) were asked to provide our views about the status and timeline for TLS 1.3; we wanted to share the same information with the WG.
>
> Before that though, we want to thank the researchers for the time they put into analyzing the protocol as well as the TRON Workshop sponsors.  The workshop was constructive and helpful.  There are a number of groups formally analyzing the protocol, some by hand and some with automated tools, they’ve already discovered issues that we’ve fixed [1].
>
> The workshop made the following clear to us wrt TLS 1.3:
>
> o - Basically OK overall, but there was some sentiment that we should only do 0-RTT with PSK (see recent list discussion).
>
> o - Some researchers prefer the key schedule that is currently documented in the draft because it eases modular analysis of the protocol. Others prefer the simplified proposals in [2,3].
>
> We are hoping to be able to do a WGLC sometime shortly after Buenos Aires (i.e., mid-April).  Of course, this timeline is entirely dependent on the WG reaching consensus on the remaining issues.
>
> At this point we are looking at reducing change to the protocol.  We are not looking to add any more features, removal of features and slight changes that improve the protocol are still on the table. Obviously, if we find any glaring issues we will fix them regardless.
>
> One thing that was reinforced at TRON and we think the TLS WG should be aware of is that the research community needs time to do their analysis.  With that in mind, the chairs are very strongly leaning towards an extended WGLC of 6 weeks.

Is the Core TLS proposal something that the Chairs and WG think should
be adopted? Essentially this is a stripped down TLS 1.3 without
dangerous bits that we encourage highly reliable implementations to
stick to. I know I still need to make a concrete proposal: probably
this weekend will see it done. The idea is that we've already done the
analysis of the Core TLS, and implementations can be significantly
simplified if they only support this core, thus removing the
possibility of very nasty bugs.

Sincerely,
Watson

>
> J&S
>
> [0] https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme
> [1] https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA
> [2] https://mailarchive.ietf.org/arch/msg/tls/uUbeVDQwJuZO_bYhOWJRvlNlNtg
> [3] https://mailarchive.ietf.org/arch/msg/tls/rgiTKwRb23T7iKjlkAQAt112ipY
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Mar 2016 18:55:27 -0800

On Tue, Mar 1, 2016 at 6:42 PM, Watson Ladd <[email-masked]> wrote:

> > At the TRON workshop [0], we (Joe and Sean) were asked to provide our
> views about the status and timeline for TLS 1.3; we wanted to share the
> same information with the WG.
> >
> > Before that though, we want to thank the researchers for the time they
> put into analyzing the protocol as well as the TRON Workshop sponsors.  The
> workshop was constructive and helpful.  There are a number of groups
> formally analyzing the protocol, some by hand and some with automated
> tools, they’ve already discovered issues that we’ve fixed [1].
> >
> > o - Basically OK overall, but there was some sentiment that we should
> only do 0-RTT with PSK (see recent list discussion).
> >
> > o - Some researchers prefer the key schedule that is currently
> documented in the draft because it eases modular analysis of the protocol.
> Others prefer the simplified proposals in [2,3].
> >
> > We are hoping to be able to do a WGLC sometime shortly after Buenos
> Aires (i.e., mid-April).  Of course, this timeline is entirely dependent on
> the WG reaching consensus on the remaining issues.
> >
> > At this point we are looking at reducing change to the protocol.  We are
> not looking to add any more features, removal of features and slight
> changes that improve the protocol are still on the table. Obviously, if we
> find any glaring issues we will fix them regardless.
> >
> > One thing that was reinforced at TRON and we think the TLS WG should be
> aware of is that the research community needs time to do their analysis.
> With that in mind, the chairs are very strongly leaning towards an extended
> WGLC of 6 weeks.
>
> stick to.

I think a "safer" profile of TLS, as in "implement the following features
(section XXX, YYY) and not the following (section ZZZ)" then that seems
like something that might potentially be a useful exercise. Depending on
length, this might eventually make sense to pull into TLS 1.3 as an
appendix or just leave as a self-contained document.

Just to preempt this, I think a separate self-contained draft would be bad.

-Ekr

> I know I still need to make a concrete proposal: probably
> > [0]
> https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme
> > [1]
> https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA
> > [2]
> https://mailarchive.ietf.org/arch/msg/tls/uUbeVDQwJuZO_bYhOWJRvlNlNtg
> > [3]
> https://mailarchive.ietf.org/arch/msg/tls/rgiTKwRb23T7iKjlkAQAt112ipY

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 14:01:28 +1100

On 2 March 2016 at 13:55, Eric Rescorla <[email-masked]> wrote:
> (section XXX, YYY) and not the following (section ZZZ)" then that seems like
> something that might potentially be a useful exercise. Depending on length,
> this might eventually make sense to pull into TLS 1.3 as an appendix or just
> leave as a self-contained document.

Yeah, something like this would have been very helpful for TCPINC.  Or
for protocols like COAP.

I think that a description of the "good parts" of TLS 1.3 would be a
relatively short document if it were self-contained.  The core is
pretty simple.

Though, as ekr mentioned, copying the main spec could be bad.  The
point of something like this is to create something that would talk to
a full implementation, not to create a protocol fork.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 1 Mar 2016 19:06:21 -0800

> a full implementation, not to create a protocol fork.

I'll make a pull request containing the text against the main document
then, and we can see how it looks from there.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Mar 2016 19:39:55 -0800

On Tue, Mar 1, 2016 at 7:01 PM, Martin Thomson <[email-masked]>
wrote:

> like

Reading this over, I wonder if we're talking about the same thing. It's
probably my fault for
using the word "self-contained" here, so in the interest of clarifying,
what I meant here was
 "separate".

Specifically, I think it's not going to work well to have a document that
(for instance)
replicates the rules about wire encodings, crypto, etc. [0]  I do think it
would probably
be OK to have a document that profiled TLS 1.3 and then referred to the
relevant
sections in the main document for details.

-Ekr

[0] Though of course simplifications to this text are welcome.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 14:43:18 +1100

On 2 March 2016 at 14:39, Eric Rescorla <[email-masked]> wrote:
> using the word "self-contained" here, so in the interest of clarifying, what
> I meant here was
>  "separate".

Yes, separate was my thought.

> sections in the main document for details.

Yes, that was my point regarding a fork.