Re: [TLS] Call for consensus: Removing DHE-based 0-RTT

On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>
wrote:

>
>
> On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner <sean@sn3rd.com> wrote:
>
>> All,
>>
>> To make sure we’ve got a clear way forward coming out of our BA sessions,
>> we need to make sure there’s consensus on a couple of outstanding issues.
>> So...
>>
>> There also seems to be (rougher) consensus not to support 0-RTT via DHE
>> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mode
>> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT are
>> almost identical,
>
>
> I am not offering an opinion about what the WG should decide regarding
> keeping
> DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note that
> the
> above claim "The security properties of PSK-based 0-RTT and DHE-based
> 0-RTT are
> almost identical" is not quite right (nothing I say here is new, I just
> felt
> that I had to "object" to this statement as written).
>
> There are some significant differences - in some cases even "fundamental
> differences" - between keeping secret state (in the PSK case) and keeping
> non-secret state (in the DHE case) or even not keeping state at all (in the
> DHE case) and retrieving the server key g^s from some external source (with
> integrity but not secrecy).  In addition, using DHE 0-RTT would require the
> client to send a key share g^x leading to a PFS 1-RTT exchange while with
> PSK
> it may be "tempting" to omit PFS.
>

The current plan of record is to allow the server to specify which cipher
suites it is
willing to accept, so it could refuse this

Moreover,  if the server's configuration
> key g^s is refreshed often (say each 5 minutes) then the g^xs key used by
> the
> client to protect its 0-RTT data already has some good level of forward
> secrecy (the attacker has a 5 minute window to find s and after that
> forward
> security is guaranteed).  The latter point touches on an important aspect
> which is the key management complexity of ticket encryption/decryption keys
> (as needed in the PSK case) vs managing secret DH key s (in the DHE case).
> I am not sure what would be done better (more secure) in practice.
>

Can you expand on the difference here? Say that the server implements
tickets
by storing a DH private key and then encrypting the ticket under the
corresponding
public key. How does this provide different PFS properties?

-Ekr

> But really it seems that the discussion boils down to identifying cases of
> enough interest where avoiding the original 1-RTT trip for establishing a
> session ticket is important. I am puzzled by the fact that the Google team
> seems ok with something that essentially voids the main feature and design
> basis of of QUIC.
>
> Hugo
>
> 
>
>> but 0-RTT PSK has better performance properties and is simpler to specify
>> and implement. Note that this does not permanently preclude supporting
>> DHE-based 0-RTT in a future extension, but it would not be in the initial
>> TLS 1.3 RFC.
>>
>> If you think that we should keep DHE-based 0-RTT please indicate so now
>> and provide your rationale.
>>
>> J&S
>>
>> _______________________________________________
>> 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
>
>