Subject: [saag] Perfect Forward Secrecy vs Forward Secrecy

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Mar 2020 10:36:10 -0400

I have been asked to change all uses of the term:

Perfect Forward Secrecy

to

Forward Secrecy

As perfection is hard to attain.

Now I am all for that, as in my  Orthodox Jewish background, Perfection 
is truly limited.  But I am quite use to the hijacking of words like 
awesome.

But the term is pretty well baked into IETF standards.

What is the 'feel' about this.

Should I start a movement of using "Forward Secrecy" and the Security 
Directorate will back this position, getting all current drafts to 
change as well?

Thank you for your opinions.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Mar 2020 14:48:22 +0000

Was the person who asked you to make the change a security person?
Can you ask them for a rationale?

I agree perfect forward secrecy is the term of art and we shouldn't create a new one.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Mar 2020 10:53:32 -0400

> Was the person who asked you to make the change a security person?

A Sec AD.

> Can you ask them for a rationale?

His preference as, "perfection is hard to attain."

> I agree perfect forward secrecy is the term of art and we shouldn't create a new one.

Why I feel this ship has sailed.

Lots in English usage I cringe at and just have to accept.

"Ecologize"  really set me off when I first heard it.  My area of study 
for my B.S. in Botany in '72 was Botanical Successional Ecology.

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 18 Mar 2020 07:59:13 -0700

> I agree perfect forward secrecy is the term of art and we shouldn't 

FWIW, +1.

Best,
Chris

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Mar 2020 15:00:04 +0000

>    A Sec AD.

That's disappointing.

>    Why I feel this ship has sailed.
  
Agreed.

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Mar 2020 10:58:45 -0500

> His preference as, "perfection is hard to attain."

The switch from calling it PFS to just FS came a long time ago -- I
don't recall exactly, but it feels like roughly a decade ago.  I'm not
sure why, and "perfection is hard to attain" does seem a bit silly
considering PFS is a term of art, but then, our terms of art get used by
snake oil salespeople.

Not that making one term of art harder to repurpose for snake oil sales
-if that was the intent- will make much of a dent.  But as you note,
this ship has sailed.

Nico
--

---

From: Dan Brown <[email-masked]>
Date: Wed, 18 Mar 2020 16:01:30 +0000

Well, the paper
https://eprint.iacr.org/2013/339.pdf
does not use the term perfect, which I think is a good idea.

Better to stop perpetuating a marketing word!  Besides, forward secrecy has not alternative meaning to worry about.

FWIW, I once presented to a bunch of quantum computing researchers, and blithely used the term "perfect" to which they strenuously, and logically, objected.

Best regards,

Dan

> -----Original Message-----
> From: saag <[email-masked]> On Behalf Of Salz, Rich
> Sent: Wednesday, March 18, 2020 11:00 AM
> To: Robert Moskowitz <[email-masked]>; [email-masked]
> Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_saag&d=DwICAg&c=yzoHOc_ZK-sxl-
> kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-
> UonsW647lYqnsrbXizKI6MgkEw&m=9ySHXHCknogS_OBxHFmfhiP5HybmGnP1
> ARI20jDHdxA&s=YAzeZGV0OLBWM983ddGInWmM4YdxVxg46aKgNpcLDEU&e
> =

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Mar 2020 11:10:56 -0500

ISTR it was Radia Perlman who told me, long ago, that we now call it FS,
not PFS.  But my memory of the chat where this came up long ago is very
fuzzy.  A brief search did not turn up anything specific.

Of all the things to worry about today, changing terms of art is not
very high on my list :/

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 18 Mar 2020 09:26:34 -0700

> > I agree perfect forward secrecy is the term of art and we shouldn't 

Wikipedia has an entry

  https://en.wikipedia.org/wiki/Forward_secrecy

which begins with a quote from

  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.

So, I still think that PFS is a term of art and we should not stop using
it.

	-- Mark

---

From: Jon Callas <[email-masked]>
Date: Wed, 18 Mar 2020 09:38:07 -0700

> On Mar 18, 2020, at 7:36 AM, Robert Moskowitz <[email-masked]> wrote:
> 
> Perfect Forward Secrecy to Forward Secrecy
> 

Please. +2^n. This is one of my peeves. Forward secrecy is a much better term. Saying "perfect" forward secrecy is kinda like "military-grade" encryption in the way it's misused, and often a shibboleth showing trying to puff things up.

In the face of "perfection" though, let me talk a bit out of the other side of my mouth. The word "perfect" its most distilled form, means something that can't be made better. Colloquially, we use it to mean something like "flawless" but its most basic form is more like "best." 

Most uses of Perfect Forward Secrecy meet neither of those. It's neither flawless nor best.

If one wants to rigorously define what "perfect" forward secrecy might look like, "information-theoretic" security is pretty close to what perfection is. It's not only rigorous, but it's got a lot of the qualities you'd want in something "perfect."

Well, we don't do that. We don't go to information-theoretic security. The reason we don't, if you'll forgive the small hand wave is that we've decided that 2^128 is a big number and moreover that it's big enough. At the same time, for people who disagree, we offer them the number of 2^256, and that's also a big enough number.

We don't do "perfect" security in our fundamentals, because, as the unnamed AD said, it's hard to achieve.

If we look at a communications system, let me idealize something like TLS into one, we do a key exchange of some object we turn into a key, and then bulk encrypt with that key. The "PFS" systems we use could be "better" (for some reasonable definition of better). Here's a sketch:

There's nothing magic about forward secrecy. It only means you throw keys away. We use one key for the whole session/transaction, and then throw it away. (And yes, I am indeed burying a lot of detail.) Well, could we make that better? If we can, then the existing system is not perfect.

It's easy to make it better -- negotiate two keys. Halfway through the session, (hand wave, hand wave) negotiate a new key so that if a key is compromised on one half, it doesn't compromise the other one. Take our idealized handshake and just do it again.

Can we do better than two keys? Sure! Four keys! Can we do better than that? Yes. If you do a full handshake for every bit you transmit, then *that* is the most forwardly-secret thing you can do. True Perfect Forward Secrecy does a full handshake for every bit.

We don't do that because it's hard, and also because it's kinda -- well, gilding the lily is the kindest way to put it. This is where notions of information-theoretic security come in.

If you're doing a handshake with 2^128 bits of security, you can safely transmit 128 bits under that handshake. You don't get more security by sending only a single bit -- it's *better* but it's a difference without distinction (cryptographically, it's a betterment without a distingusher, hahaha). Thus, while True Perfect Forward secrecy does a handshake for every bit, Operationally Perfect Forward Secrecy sends as many bits as the security level of the handshake and no more.

(From this, we can also note that Truest Operationally Perfect Forward Secrecy would do a handshake with a security level of a number of bits that's the whole of the session, so you can send the whole thing in one handshake. Note that when you do this, you don't actually need to have a bulk cipher -- instead of doing "key exchange" we can just do "message exchange.")

We don't do anything like this. We don't because we have a collective, unstated hunch that it's okay to use a key and send a lot. We even have guidance and work on how big "a lot" should be. This is where birthday-bounds issues, nonce issues, and so on all come in. (As usual, yes, GCM, I'm looking at you.)

Summing up, I kinda agree with the AD that "perfection is hard to achieve" while going further that perfection is *undesirable* because it carries with it a lot of baggage that we don't want to carry -- like the baggage of doing handshakes.

Most importantly and relevant, we should stop saying "perfect" because it's false. At no point where we're doing forward secrecy are we perfect. We could do better. We make the engineering decision to do Good Enough Forward Secrecy. 

Yes, yes, drop "Perfect." It should be just "Forward Secrecy" with no editorializing, especially when it's just not true and even downright misleading.

	Jon

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Mar 2020 09:38:32 -0700

I don't feel strongly about this, but would make three points:

1. RFC 4949 seems to have both terms, with the main
definition under PFS and FS pointing to PFS and then says:

   Ordinary forward secrecy vs. "perfect" forward secret: Experts
   disagree about the difference between these two. Some say there is no
   difference, and some say that the initial naming was unfortunate and
   suggest dropping the word "perfect". Some suggest using "forward
   secrecy" for the case where one long-term private key is compromised,
   and adding "perfect" for when both private keys (or, when the
   protocol is multi-party, all private keys) are

2. TLS 1.3 explicitly chose to use the term "forward secret" and not
"perfect forward secret".

3. One advantage of saying FS and not PFS is that you can then describe
things as "forward secret" in a way that isn't grammatically awkward,
as in RFC 8446; S 2.3.

   1.  This data is not forward secret, as it is encrypted solely under
       keys derived using the offered PSK.

-Ekr

On Wed, Mar 18, 2020 at 9:30 AM Mark D. Baushke <mdb=
[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/saag
>

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 18 Mar 2020 09:45:52 -0700

>        keys derived using the offered PSK.

All good points! I based my opinion on the HAC definition, though 
Jon’s response nudged me the other way. (Thanks, Jon!)

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Mar 2020 11:47:20 -0500

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

Nico
--

---

From: "Hao, Feng" <[email-masked]>
Date: Wed, 18 Mar 2020 17:16:51 +0000

The use of PFS is very prevalent in the past literature on key exchange. In 2010, when I was working on the YAK protocol [1], I did wonder why the term PFS was used everywhere despite that the word "perfect" obviously has no concreate meaning. At the time I found the very few papers that suggest the word "perfect" in PFS is redundant are MQV papers (1998, and the later 2003 journal version). In [1], I explicitly dropped the word "perfect" from PFS as it really has no concrete meaning. But within the context of the protocol that I was designing, I defined half/full forward secrecy to explicitly distinguish the two cases that when one or both parties' static keys are compromised. 

[1] https://eprint.iacr.org/2010/136.pdf

Cheers,
Feng

On 18/03/2020, 15:59, "saag on behalf of Nico Williams" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Nico
    --

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Mar 2020 10:17:35 -0700

> 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

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Mar 2020 14:31:04 -0500

> and I'm not quite sure it's that useful.

+1.  Calling this just FS and not PFS is fine with me, even if fear of
misunderstanding "perfect" strikes anyone as silly.

> this PFS or just FS? Depends on where you draw the line for "agreed key",

+1

> https://tools.ietf.org/rfcmarkup?doc=8446#section-8.1

+1.

---

From: Dan Brown <[email-masked]>
Date: Wed, 18 Mar 2020 20:26:19 +0000

> From: saag <[email-masked]> On Behalf Of Dan Brown

I prefer "forward secrecy" (or forward security), so no "perfect", please.  [To clarify my ambiguous grammar above with a clause appended to negation, oops.] 

The bike-shed color "perfect" should be avoided because it is too garish, metaphorically. The term "perfect" is unclear and inaccurate, no matter what formal definition is attached to it. 

The term-of-the-art justifications for perpetuating "perfect" are imperfect, based on my limited understanding of the art, but also based on the general principle of reform, evolution, and improvement, ever towards a more perfect world.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 22 Mar 2020 18:19:40 -0700

> We don't do "perfect" security in our fundamentals, because, as the unnamed AD said, it's hard to achieve.

For what little it's worth, the AD doesn't have to be unnamed; I'm happy to
own up to making the request of Bob.  I just haven't gotten fully caught up
on mail yet.

-Ben

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 23 Mar 2020 13:57:26 -0400

> own up to making the request of Bob.  I just haven't gotten fully caught up

And draft 17 reflects this view of Forward Secrecy.

Thanks, Ben.