Re: [saag] Perfect Forward Secrecy vs Forward Secrecy

Jon Callas <joncallas@icloud.com> Wed, 18 March 2020 16:38 UTC

Return-Path: <joncallas@icloud.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BF03A1831 for <saag@ietfa.amsl.com>; Wed, 18 Mar 2020 09:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.561
X-Spam-Level:
X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz6usP5g1_Xi for <saag@ietfa.amsl.com>; Wed, 18 Mar 2020 09:38:10 -0700 (PDT)
Received: from pv50p00im-ztbu10011701.me.com (pv50p00im-ztbu10011701.me.com [17.58.6.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2955B3A0138 for <saag@ietf.org>; Wed, 18 Mar 2020 09:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1584549489; bh=yrHinqKGTQM1Kwf3il0+/X5j/21M6mcDpYJcwE0XYJM=; h=Content-Type:Subject:From:Date:Message-Id:To; b=yCz9xamFD/Yo53kHrSsVgcBnLrJ8kqxPhUul6FFWmQdRI+Cyg+1gvJPOSsW6pJru/ Vx+PD9nbT+X1eZH0eH7C9e7ehIuRZrkomxl2ZWtPXgGkrhM+ahRg/nawJeU/kNXwFf lQNRIIgNAUqrSm4dkebty9bjVipyjROYcTug/eRrcV4rxEAUsruQWtTur/edDUWXVz F/5eIoVR3tx/zuiLvQBWMi8/MiXaaS7f5LX7Hzxi2SlosZH0sRp9lpswXn/YH7co8P By/xq0yn5wXc+Fojkf00TNVaFwVQXvGtoJXbhoKHFSlEtuAEg45Xi1w0u2Nx7rYJQT ZRu8xccoTRlgg==
Received: from [192.168.7.69] (thing1.merrymeet.com [173.164.244.99]) by pv50p00im-ztbu10011701.me.com (Postfix) with ESMTPSA id C7D1C8A01F1; Wed, 18 Mar 2020 16:38:08 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Jon Callas <joncallas@icloud.com>
In-Reply-To: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com>
Date: Wed, 18 Mar 2020 09:38:07 -0700
Cc: Jon Callas <joncallas@icloud.com>, saag@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BAFBB844-0AB4-41A5-9A15-B9CED6F6602C@icloud.com>
References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-03-18_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=916 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2003180075
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/ky8lM0Gdg7Pvas1D7CHU0IiLwTE>
Subject: Re: [saag] Perfect Forward Secrecy vs Forward Secrecy
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2020 16:38:12 -0000


> On Mar 18, 2020, at 7:36 AM, Robert Moskowitz <rgm-sec@htt-consult.com> wrote:
> 
> I have been asked to change all uses of the term:
> 
> Perfect Forward Secrecy to Forward Secrecy
> 
> What is the 'feel' about this.
> 

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