Re: Forward Secrecy

hal@finney.org ("Hal Finney") Mon, 28 February 2005 18:58 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22068 for <openpgp-archive@lists.ietf.org>; Mon, 28 Feb 2005 13:58:12 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SISfTu094779; Mon, 28 Feb 2005 10:28:41 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SISfX0094778; Mon, 28 Feb 2005 10:28:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SISe0k094761 for <ietf-openpgp@imc.org>; Mon, 28 Feb 2005 10:28:41 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 2C6BA57EBA; Mon, 28 Feb 2005 10:41:09 -0800 (PST)
To: ietf-openpgp@imc.org
Subject: Re: Forward Secrecy
Message-Id: <20050228184109.2C6BA57EBA@finney.org>
Date: Mon, 28 Feb 2005 10:41:09 -0800
From: hal@finney.org
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I think we had some discussion of this a few years ago, but I don't
have my records handy.  I do like the idea of forward secrecy but I
think there are a few problems with the proposals in the draft
http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt.

   Using a series of encryption keys, each with a short lifetime,
   reduces the information revealed by the compromise of any one private
   key because each key protects less data.  If expired keys are
   securely deleted, attackers will never be able to retrieve them to
   decrypt captured ciphertext.  Therefore when a public encryption key
   expires, an OpenPGP client MUST securely wipe the corresponding
   private key [4].

I don't agree that OpenPGP clients MUST always securely wipe expired
private keys.  In the context of a user who wants PFS, this makes sense.
But for a user who wants to be sure he can decrypt his messages, this
is a bad policy.  For example, some mail systems may store the messages
in encrypted form, and he needs to keep the key around in order to read
those messages in the future.

We would need to make the wording clear that this is only for clients
operating in "PFS mode".

   Deletion should take place once all messages that could have been
   sent before expiry have been received and decrypted.  For example, as
   a user logs on, their mail client SHOULD retrieve and decrypt all
   messages from their mail server before deleting any newly-expired
   private keys.  A "panic mode" MAY bypass this step.

I guess that "panic mode" means some command the user could give to
immediately delete all expired decryption keys.

But this leads to a larger concern, which is that much of this draft
specifies client behavior in a manner which has traditionally been out
of scope for our working group.  We would not normally propose to give
guidelines for UI such as the existence of a panic mode, and how clients
should respond to it.  For example, we do not attempt to prescribe how
client software should display signed messages, what information should
be shown from a signature, or how to depict messages which are partially
signed and partially unsigned.

The PFS draft is full of detailed recommendations about client behavior.
Here, it describes how and when clients should access the mail server.
Later, it talks about clients sending various warnings to each other,
generating keys in the background, and revoking keys before exporting
the private part.  The main thrust of the draft is towards specifying
client behavior.

My principle concern is that since we have eschewed such specifications
even for the more fundamental task of communicating securely via email,
does it make sense to go into such detail for a rather more specialized
sub-task, of achieving PFS in the process?  Here is another example:

   Clients receiving messages encrypted with a revoked key MUST warn the
   sender that they should not use that public key again.  Any relevant
   key revocation certificates MUST be included in the warning.

This is not really PFS specific, and it may be a good idea, but it is
exactly the kind of thing which we have left out of the OpenPGP spec.
There are too many issues involved in the design of a mail user agent
for a secure email system, for us to try to capture them in a spec.

I won't try to go through the rest of the draft at this time.  As I said,
I support the goal of PFS, but I am skeptical about whether it makes
sense for our WG to promulgate such detailed advice on a relatively
narrow aspect of security.

Hal Finney