On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk <h...@ee.technion.ac.il> wrote: > > > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <davemgarr...@gmail.com> > wrote: >> >> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: >> > I propose that we remove DH-based 0-RTT from TLS 1.3. >> > >> > As ekr's previous mail noted, the security properties of PSK-based >> > 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is >> > much more complex. >> > >> > For those who love DH-based 0-RTT, and I know that some people are >> > fans, here's something that might make you less sad about removing it >> > from the core spec. You can use DH out of band to negotiate a PSK. >> > You might even do this as an extension to TLS, but that's of less >> > value. >> >> I think there is a good argument for moving DH 0RTT into a TLS extension. >> Implementations that are explicitly not going to use it should not be >> expected to implement it and risk screwing it up. If we accept that premise >> that online DH 0RTT will be unlikely in practice, then we would be >> specifying it at least primarily for out-of-band use, and doing it via an >> extension will probably be cleaner and safer. > > > Combining this comment (which I agree with) with the following comment from > Watson in another thread: > >> > If they rely on extensions then either those >> > extensions need to be included in the security proofs, or we need to >> > make clear that they are not as secure as TLS 1.3, and that >> > implementations which enable both of them can get completely wrecked >>in new and exciting ways. > > We get that even if it is decided not to include the DH-based 0-RTT as part > of mandatory-to-implement TLS 1.3, it should be defined as an extension and > as part of the TLS 1.3 document. Leaving the reduction from this case to PSK > (as Martin suggested) to popular imagination is too dangerous. By including > it as part of TLS 1.3 official text we also encourage the groups that are > currently analyzing the protocol to include this specific mechanism in their > analysis. If they find something wrong with it then even more reason to do > the analysis. > > >> >> I would still prefer it be defined in the TLS 1.3 specification document, >> though optional. > > > I suggest to also define TLS 1.3-EZ. > A subset of core safe functionality that should address the majority of the > usage cases.
I strongly encourage this proposal, and will even massacre the markdown to attempt it. I also commit to implementing TLS 1.3-EZ in Go, and possibly in C based on Amazon's s2n. (A trustable X509 library in C is still beyond my reach, so that C might be server-only). > > Hugo > > >> >> >> >> Dave >> >> _______________________________________________ >> 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
