Re: [saag] Perfect Forward Secrecy vs Forward Secrecy

Eric Rescorla <ekr@rtfm.com> Wed, 18 March 2020 16:39 UTC

Return-Path: <ekr@rtfm.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 C79983A184A for <saag@ietfa.amsl.com>; Wed, 18 Mar 2020 09:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 OzbXiXk0eKNB for <saag@ietfa.amsl.com>; Wed, 18 Mar 2020 09:39:11 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1913A0477 for <saag@ietf.org>; Wed, 18 Mar 2020 09:39:10 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id s13so27820785ljm.1 for <saag@ietf.org>; Wed, 18 Mar 2020 09:39:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=14jX1kx1HdJVoYOi8ESpMhzp/clJCYVHxtZ3kBUjas8=; b=qAhG292FfVQ4irXinY7NLpPBeYZ53QhOR3DN03D0HjnFPZLup/SVJEDPDCyrdj/ek0 JeL5Xc+jFUhpwDwwyzS5TCAnP3dH53f9J6p3E4SbNMUbFTf5S6lSUpxjHFdeg4zApu9R TUo92VEBY9Lv9A3nAVyn0qh1Fw0mljDY+ma7etzBDpY+WKymJDh+mgNG7HOfuKy/Q5vv FadG855o0VjB9+4cPKfihDlvrxZT08jq/AFjzE3Ig2OmL742xgD1wIYEbsmZEyFnG6kM SY/xu7Bc0zi6hJquks7sohfIXY2xgGKW865JpzIVuylX2geMAJuKYJJivyl97cqScSMN ssuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=14jX1kx1HdJVoYOi8ESpMhzp/clJCYVHxtZ3kBUjas8=; b=nSj0sqdQewwc3c72sL0rKzqXV7tcTB9Difn/7/Fev2DBWKXohOMhHeGp/2Ft5WzJF4 fG/+p0mxJOh4DCwvcMF5d16P8QNSZld3mmEbCO/Wt35cLbTjXa4It19zisE0EkXrQqiu L83Q1t8S8tc4r9DjQ2uNmtKlDfCJWD+bi8osl3P7nQGvM0zQ5UJHVhcyy7zqcdqLhHgP iWgDq96beJY43f2aGfKv5hKy4EqJp9eZw3ezSzTSftTqEuZpziO2LmBhYd297XX/dUFN OD5ADbJrzxC9AD0xL8sGwwAfG7a8+ovBouhk5J94l+Lzl+RvclSfgr5oGfc7Hg3CGLtc nUXg==
X-Gm-Message-State: ANhLgQ2xYsCxAkXdRHiaU/I62wkc7eLqnZMVVZoE4095So29n4twaP7O /9ajHrKuUPxIO5WN2g4xlerLSAn0YvpDIZFHhWCdnNVv8zhOOg==
X-Google-Smtp-Source: ADFU+vu85DL7VLNot9Icduiorzkb5mf487PR3EEYpdgpHbzanl/Dq4WP0fQSaZOp9MIgF58/RzbuVSXGw/b6gZuwQGI=
X-Received: by 2002:a2e:8246:: with SMTP id j6mr2407826ljh.162.1584549548768; Wed, 18 Mar 2020 09:39:08 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <3517.1584548794@eng-mail01.juniper.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 18 Mar 2020 09:38:32 -0700
Message-ID: <CABcZeBOFLLYK3LZWQ_dSptQPc1u7=pOS6QWcJZu0sPGn9X_iVw@mail.gmail.com>
To: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>
Cc: saag@ietf.org, Christopher Wood <caw@heapingbits.net>
Content-Type: multipart/alternative; boundary="000000000000fbd19a05a123b0dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/ob6Hn6AlD8RW7RpXeBHF1fzCed4>
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:39:13 -0000

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=
40juniper.net@dmarc.ietf.org> wrote:

> Christopher Wood <caw@heapingbits.net> writes:
>
> > On Wed, Mar 18, 2020, at 7:48 AM, Salz, Rich wrote:
> > > I agree perfect forward secrecy is the term of art and we shouldn't
> > > create a new one.
> >
> > FWIW, +1.
>
> 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
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>