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

[Benjamin Beurdouche <[e-mail]>]

> On Jan 18, 2020, at 11:51 AM, Karthik Bhargavan <[e-mail]> wrote:
> 
> 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?)

Ah : ) I guess it all depends on what you build on top of the AKE of course...
But anyhow, TLS is short-lived and even in the case of longer sessions using session tickets,
both peers can decide to start a fresh session by starting a fresh 1RTT handshake, correct ?

The argument of using PSK in contrast of DH to provide FS leads to the thinking that those are equivalent,
which obviously both you and Ekr point out not to be the case regarding PCS and compromise in general.

So, if you tell me that LAKE will provide a mechanism <insert name> (e.g.FS) that enables us to recover secrecy from a
passive compromise while most of the time using the PSK rotation for FS, I am willing to say it is ok.
Otherwise, if there is no hope to introduce freshness via <insert mechanism> (e.g.FS) and that a compromised session will always
remain compromised, I’ll maintain that we cannot claim this to be a secure AKE for protocols we’ll build on top...

For some reason, I see the claim “DH is too costly” has having the dangerous implication
“let’s do long term sessions with PSKs” and I think this is quite dangerous but I might be completely wrong here… : )

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

B.