On Tue, Jan 12, 2016 at 9:13 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > Hi, Peter > > Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) > that this WG is working on right now, why? > > Other groups are not working on HTTP/1.2 or IKEv1.1 or any other > $protocolv$(major-1).$(minor+1). > > Any TLS library that exists now doesn’t have an implementation of either > “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to get an > upgraded version of your favorite library. So the upgrade path is no smoother > for either protocol. If this had been brought up before the work on the > current draft started, maybe we would be convinced. As it is, I don’t see the > point.
Not if TLS 1.2.1 is a subset of TLS 1.2, similar to the UTA profile. In fact, that's what happened the last time this idea was raised: it got kicked over to UTA. > > Yoav > > >> On 12 Jan 2016, at 4:03 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> 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, >> namely: >> >> Bhargavan et al, "Proving the TLS handshake secure (as is)". >> >> Brzuska et al, "Less is more: relaxed yet compatible security notions for key >> exchange". >> >> Dowling et al, "Modelling ciphersuite and version negotiation in the TLS >> protocol". >> >> Firing, "Analysis of the Transport Layer Security protocol". >> >> Gajek et al, "Universally Composable Security Analysis of TLS". >> >> Giesen et al, "On the security of TLS renegotiation". >> >> Jager et al, "On the security of TLS-DHE in the standard model". >> >> Krawczyk et al, "On the security of the TLS protocol". >> >> (and probably several more) and use them to simplify TLS 1.2 to create an >> improved TLS that leverages about 15 years of analysis, rather than creating >> what's almost a new protocol based on bleeding-edge/experimental ideas, >> mechanisms, and algorithms. >> >> The discussion started out somewhat informally so by the time it got really >> interesting it was too late to take notes, but I thought I'd try and recreate >> the design points... >> >> - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC + >> HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC- >> SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB >> instead of GCM as the AEAD if it were freely available). >> >> - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as >> well). >> >> - Get rid of the IPsec cargo-cult MAC truncation. >> >> - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to >> allow verification (for those who don't have a copy of X9.42, it requires >> the same verification steps as FIPS 186 does). Also, mix the hash of the >> DHE values into the computed premaster secret to protect against use of >> manipulated curves. >> >> - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check >> done as encode-then-compare, which fixes all known padding-manipulation >> issues). >> >> - No compression or rehandshake. >> >> - Replace the PRF with HKDF? (No pressing need for this, but it would be >> part >> of the general cleanup). >> >> Longer discussion points: >> >> - The DHE/ECDHE parameters were a bit contentious. For DHE the choice is >> between server-specified ephemeral parameters and IETF-blessed fixed ones. >> Arguments can be made either way, we had de facto IETF-blessed fixed DHE >> params in the form of the RFC 2409 ones, but that wasn't such a good idea. >> OTOH with ephemeral DHE params many implementations didn't check them, but >> then the spec never required any checking (or much of anything at all in >> regard to DHE use, which no doubt contributed to some of the dubious >> practices that have been found in the wild). The situation wasn't helped by >> the use of the PKCS #3 representation, which the requirement to use the >> X9.42 form alongside the accompanying checks attempts to address. >> >> - Similarly, for ECDHE the choice is between NIST and CFRG ones. The CFRG >> ones are obviously better (for various values of better, see endless debates >> elsewhere), but some people will insist on only using something that's come >> from NIST (I'll reserve my opinion on that one, and wouldn't dream of >> stooping to phrases like "cargo cult protocol design"...). >> >> Peter. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
