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

Removing DH based 0-RTT would make it more important to make the lifetime of the ticket enforced.

One interesting difference is that DH based 0-RTT requires proof of possession of the private key for the client to accept the connection, however PSK based 0-RTT might not be associated with a certificate at all. Thus the only way to prove that the key is still fresh is to limit the time that the PSK is valid and strictly bound that time. Unless we add a way for the client to require a server authentication during PSK resumption.

This is relevant in situations where compromise of the ephemeral key does not mean that the long term private key has been compromised like in ssl offloading type scenarios.

Subodh Iyengar
________________________________
From: TLS [tls-bounces@ietf.org] on behalf of Eric Rescorla [ekr@rtfm.com]
Sent: Tuesday, February 23, 2016 11:42 PM
To: Watson Ladd
Cc: tls@ietf.org
Subject: Re: [TLS] Remove DH-based 0-RTT

On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd <watsonbladd@gmail.com<mailto:watsonbladd@gmail.com>> wrote:
On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk <hugo@ee.technion.ac.il<mailto:hugo@ee.technion.ac.il>> wrote:
>
>
> On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <davemgarrett@gmail.com<mailto: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<mailto:TLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=EoheRUAdZH7W_a384ARn0T_WL5c3mFNpiUQPcze2j_g&s=zk_uHWMVkpGkuJ8OSCl7M6Xq8kisJzYYWzB8mlPo_ms&e=>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org<mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=EoheRUAdZH7W_a384ARn0T_WL5c3mFNpiUQPcze2j_g&s=zk_uHWMVkpGkuJ8OSCl7M6Xq8kisJzYYWzB8mlPo_ms&e=>
>

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

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=EoheRUAdZH7W_a384ARn0T_WL5c3mFNpiUQPcze2j_g&s=zk_uHWMVkpGkuJ8OSCl7M6Xq8kisJzYYWzB8mlPo_ms&e=>