Re: [TLS] Remove DH-based 0-RTT

On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>
> wrote:
> >
> >
> > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <davemgarrett@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
>