On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen <pzbo...@gmail.com> wrote: > On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <davemgarr...@gmail.com> wrote: >> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote: >>> Martin's comment reminded me of the following that I've been meaning to >>> post... >>> >>> In a recent discussion among some crypto folks, the topic of what TLS 1.3 >>> could be came up. Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path >>> from >>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is. The >>> discussion >>> centered around the fact that we already have lots of analysis done for TLS >>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3 >>> problems while being as compatible as possible with existing infrastructure. >>> So what this would do is take existing security analysis applied to TLS, >> [...] >> >> Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks. >> >> I'll be the bearer of bad news and tell you that your proposal has come up >> in multiple forms. I suggested a similar thing a while back and far before >> me others have as well. The chairs have, however, long declared consensus >> that we want to focus on a single new version not leaving out other more >> complex changes, namely latency improvements. > > Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter > way to go to document a profile of TLS 1.2 that covers almost all of > this. From a quick read, existing RFCs and I-Ds cover most of this: > - RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256) > - RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256) > - RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256) > - RFC 7366 (EtM) > - RFC 7627 (extended master secret) > - RF 4055 (RSA-PSS) > > The gaps seem to be: > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated > (BoringSSL has an implementation using cipher suite 0xca,0xfe)
Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite. Still no cipher suite allocated, but there is an active draft. > - DH parameters -- the alternative would be using FFDH named groups > (draft-ietf-tls-negotiated-ff-dhe-10), right? > > This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right? > > Thanks, > Peter _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
