On Tue, Mar 1, 2016 at 6:42 PM, Watson Ladd <[email protected]> wrote:
> On Mon, Feb 29, 2016 at 6:45 AM, Sean Turner <[email protected]> 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 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 > 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 protected] > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
