Re: [Lake] Forward Security with PSK-Only LAKE

[Karthik Bhargavan <[e-mail]>]

Hi Ekr,

Indeed, the PSK-only protocol I described does not provide post-compromise security (PCS).
But as far as I understand, PCS is not a requirement for LAKE, just as it is not a requirement for TLS 1.3.
(Benjamin, I don’t think you meant to suggest that we cannot call TLS 1.3 a secure protocol?)

Introducing PCS as a requirement would require a larger discussion and more justification.
In any case, we are not yet in the stage of discussing specific protocol designs.
My main motivation was to clarify that we could reuse ideas from TLS resumption to provide a forward secure LAKE without requiring DH.

Best,
Karthik

> On 18 Jan 2020, at 07:58, Benjamin Beurdouche <[e-mail]> wrote:
> 
> Yeah, btw, I think it is a minimal requirement to have FS but let’s not call LAKE a secure protocol if it is not gonna provide both FS and PCS for long term sessions...
> B.
> 
>> On Jan 18, 2020, at 1:38 AM, Eric Rescorla <[e-mail]> wrote:
>> 
>> 
>> Thanks Karthik.
>> 
>> Just to sharpen this point: you *do* need a new DH exchange to get PCS, but not to get PFS.
>> 
>> -Ekr
>> 
>> 
>> On Fri, Jan 17, 2020 at 2:58 AM Karthik Bhargavan <[e-mail] <mailto:[e-mail]>> wrote:
>> It looks like I over-simplified the protocol.
>> Some clarifications and corrections below.
>> 
>> At the beginning of a session: 
>> A and B have a PSK K, associated with id I, and a session counter C
>> 
>> ---
>> A -> B: m1 = N_A, I, C, other_params
>> B -> A: m2 = N_B, other_params, MAC(K_mB, m1 | m2)
>> A -> B: MAC(K_mA, m1 | m2)
>> A -> B: AEAD(K_eA, msg0,…)
>> B -> A: AEAD(K_eB, msg1,…)
>> ——
>> 
>> At the end of a session:
>> A and B set C <- C + 1, K <- HKDF(K, I, C+1)
>> A and B throw away the old PSK K.
>> 
>> Note:
>> - N_A and N_B are nonces generated by A and B, respectively.
>> - K_mA = HKDF(K, “mac_key A”, m1 | m2)
>> - K_mB = HKDF(K, “mac_key B”, m1 | m2)
>> - K_eA = HKDF(K, “ae_key A”, m1 | m2)
>> - K_eB = HKDF(K, “ae_key B”, m1 | m2)
>> 
>> 
>> 
>> > 
>> > --------
>> > 
>> > The above protocol can be generalized in several ways.
>> > First, A and B need not have exactly the same counter C, instead they could negotiate the MAX of their two counters and derive the PSK corresponding to that counter.
>> > Second, A and B may share both a long-term PSK K0 and an ephemeral PSK K and mix them both together in the protocol above. 
>> > This provides a clean separation between the PSK used for authentication and the PSK used for forward secrecy.
>> > Third, we may use the protocol above as a “fast resumption” mechanism but fall back to full PSK-ECDHE whenever we want.
>> > 
>> > To conclude, I wonder if we should explicitly consider a mechanism like the above as a requirement for LAKE.
>> > It appears to meet the security goals we have set for PSK-LAKE and it is a good example of what can be achieved without an expensive DH operation..
>> > (Incidentally, the message sizes of the protocol above are very tiny.)
>> > 
>> > -Karthik
>> > 
>> > 
>> > 
>> > 
>> > -- 
>> > Lake mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/lake <https://www.ietf.org/mailman/listinfo/lake>
>> 
>> -- 
>> Lake mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/lake <https://www.ietf.org/mailman/listinfo/lake>
>> -- 
>> Lake mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lake