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

[Hugo Krawczyk <[e-mail]>]

On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <[e-mail]>
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.

Hugo
 ​


>
>
> Dave
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>