Re: [saag] Perfect Forward Secrecy vs Forward Secrecy

Christopher Wood <caw@heapingbits.net> Wed, 18 March 2020 16:45 UTC

Return-Path: <caw@heapingbits.net>
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 E37D83A1886 for <saag@ietfa.amsl.com>; Wed, 18 Mar 2020 09:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=UbDDXAnB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=0DxK3vi1
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 mWAE_KaQcaLg for <saag@ietfa.amsl.com>; Wed, 18 Mar 2020 09:45:56 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688183A187E for <saag@ietf.org>; Wed, 18 Mar 2020 09:45:56 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F14055C0200; Wed, 18 Mar 2020 12:45:54 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 18 Mar 2020 12:45:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= XHLMSGTtyMc5EI//O5gw6oJgbmKydcqF5Yg5tU+KsiE=; b=UbDDXAnBvTqB7KI2 oaavVyIsiMtTHYaowXfrtLxnQXYN2WqHT1wGqLMIvBs/gIvcmHjN+ZPsuZ64tm5D 6z0kePVII45Szcfxc7yMLtk2ie6/21gsxgrchezYtBYh0Wmt5w5wiexO8vGOhqmc FhDHbC4fkK5bEqt79xXcjCvHud9i3/QrG6iPnOO/wOGCDgBS/vRTRqPbED9vwKHL q9g1Y8h6RtgNOQEFw0lPHx9t7ICHtlLQD6cOyvfflgtYAxui7iyYutthza+MaQK6 flBJoxYInsTVuZGgmRpkqLZfaNRQKPdvk+/DaA1Cbld3aN1006zo+NTShtN1nBMG Nr/9Pg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=XHLMSGTtyMc5EI//O5gw6oJgbmKydcqF5Yg5tU+Ks iE=; b=0DxK3vi1fgo8nUywBVCAefQ2mRSkobLycRlsec1VOGT15vIl45f+WA7kZ 2u0LInTY1UCne5aq7B/WqHH4LA/FlnzVWZlQAnmFmzaHzOAZqdE5ZMznydVVEjF5 z/nG9yRdf++XHYdFtteY6tgZf/Z+LJdvDU6ijo6Q5LowTdS8SoGsfsuTuG8FD+Yv +/5mQvZ35BR6THdGrahT/1ab5BBsFnHXV3rt6uUWPR5qU3FoHZySuSc2lHO/PHxw oDkf1MzJyDOB/KFdAwCOPp3IE0JyQ2ctl9WUzGPzYFxb2R44xbwrAv2PftUlIiZc Wr1+jT3tPZZVD33Kkvcdm/utRjo9g==
X-ME-Sender: <xms:QVByXtaoJoTm07G4KLUIIHtNSJOoJ_R4HDYvUpb0Ks5y34FPXfQ8pw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffokfgjfhggtgfgsehtke hmtdertdejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucfkphepjeefrdelvddrieegrddufedtne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfies hhgvrghpihhnghgsihhtshdrnhgvth
X-ME-Proxy: <xmx:QVByXuujSCmh3C4WmDZrCR7aAXemQW8GA2Cu1Atfmep3a6oIklziJQ> <xmx:QVByXqPXNnuC5UFcyDAT1xgyFGE3IwFoD-aN7ZQxrpDCdxu53DA7UA> <xmx:QVByXh43DMZvWXIx7gCz4xgUo-TCn7WDtIxOvc5UiWeVmSd6TXQTwQ> <xmx:QlByXgZ6_e_KG85vI5CQxjlBwvD-8_SqOvGoGIvfejF3AEcP3v59DQ>
Received: from [10.0.0.184] (c-73-92-64-130.hsd1.ca.comcast.net [73.92.64.130]) by mail.messagingengine.com (Postfix) with ESMTPA id 7ED633061DC5; Wed, 18 Mar 2020 12:45:53 -0400 (EDT)
From: Christopher Wood <caw@heapingbits.net>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>, saag@ietf.org
Date: Wed, 18 Mar 2020 09:45:52 -0700
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <EAF2B7B5-2366-4FFE-BC15-D03C87A55696@heapingbits.net>
In-Reply-To: <CABcZeBOFLLYK3LZWQ_dSptQPc1u7=pOS6QWcJZu0sPGn9X_iVw@mail.gmail.com>
References: <7231a98e-e4a2-55c9-3a51-d62886d7d061@htt-consult.com> <F318A864-CC99-47F7-BEFF-608F93AEB451@akamai.com> <6b73afd0-6eda-4533-a499-166934702f6e@www.fastmail.com> <3517.1584548794@eng-mail01.juniper.net> <CABcZeBOFLLYK3LZWQ_dSptQPc1u7=pOS6QWcJZu0sPGn9X_iVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/BjX_wRkSwFt7t05oBs1MmCPkcFM>
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:45:58 -0000

On 18 Mar 2020, at 9:38, Eric Rescorla wrote:

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

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