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

[Watson Ladd <[e-mail]>]

On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk <[e-mail]> wrote:
>
>
> 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.

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.