On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd <watsonbl...@gmail.com> wrote:
> 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. Great. Let's sync up as we get a little closer to done. 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). > I believe Richard Barnes has already started something along these lines, so maybe you guys could join forces (not sure how confident he is in it). https://github.com/bifurcation/mint This library currently interoperates with my experimental implementation in NSS. -Ekr > > > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
