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

[Hugo Krawczyk <[e-mail]>]

On Thu, Mar 31, 2016 at 11:49 PM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk <[e-mail]>
> wrote:
>
>>
>>
>> On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner <[e-mail]> 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
>
>
​I was just wondering if this is what will happen in practice.
But I should have separated this consideration (and the next) from the more
fundamental point of public vs secret state.


>
>
> 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?
>

​It doesn't. And you don't need a public key for this. If the server
rotates the ticket encrypting key ​

​often (say each 5 minutes as in the example) then you get the same effect.
The point was about which case, g^s or symmetric ticket encryption key will
be managed better in practice. I don't have an answer.

Hugo


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