Re: [saag] Perfect Forward Secrecy vs Forward Secrecy

[Eric Rescorla <[e-mail]>]

On Wed, Mar 18, 2020 at 9:47 AM Nico Williams <[e-mail]> wrote:

> On Wed, Mar 18, 2020 at 09:26:34AM -0700, Mark D. Baushke wrote:
> >   Menzies, Alfred; van Oorscot, Paul C.; Vanstone, SCOTT (1997).
> >   Handbook of Applied Cryptography. CRC Pres. ISBN 978-0-8493-8523-0.
> >
> >       In cryptography, forward secrecy (FS), also known as perfect
> >       forward secrecy (PFS), is a feature of specific key agreement
> >       protocols that gives assurances that session keys will not be
> >       compromised even if the private key of the server is compromised.
> >
> > There is also https://www.perfectforwardsecrecy.com/ which has a
> paragraph
> >
> >       Forward Secrecy has been used as a synonym for Perfect Forward
> >       Secrecy but there is a subtle difference between the two. Perfect
> >       Forward Secrecy has the additional property that an agreed key
> >       will not be compromised even if agreed keys derived from the same
> >       long-term keying material in a subsequent run are compromised.
> >
> > along with more justification of differences.
>
> Are there examples in Internet protocols of FS key agreement protocols
> that aren't also PFS?  I'm not denying that it's possible to construct an
> FS-but-not-PFS key agreement protocols, but I'm wondering whether we
> need a name for those when we wouldn't want to have any of them.
>

I've honestly never seen this particular distinction of FS vs. PFS drawn
and I'm not quite sure it's that useful.

Consider the case of a typical SIGMA-based AKE like TLS. The handshake
protocol typically spits out one piece of shared entropy (e.g., the TLS 1.2
master secret) which is then key expanded into multiple working (traffic)
keys. Assuming a strong KDF, then generally working key A cannot be used to
derive working key B. However, the MS can be used to derive A or B. So is
this PFS or just FS? Depends on where you draw the line for "agreed key",
right?

To make things more complicated, when you have a protocol that offers
resumption (as with TLS) you have to be able to talk about the FS
properties of resumed data, which may be different from those of the rest
of the data. As a concrete example:

- In TLS 1.2, you need to store the MS as long as you want resumption,
which means that compromise of the session database at time T2 also
compromises stored sessions from time T1 < T.
- In TLS 1.3, the resumption master secret is different from the MS, so
compromise at T2 doesn't compromise T1 if you use a session database and
delete promptly. However if you use session tickets, then the STK threatens
PFS. So in this case, it's not even a property of the AKE.

ISTM that using "perfect" or not doesn't convey enough info and we should
instead talk about protocols being forward secure with respect to certain
attacks (as is the case in MLS). See for instance:
https://tools.ietf.org/rfcmarkup?doc=8446#section-8.1


-Ekr