Re: Forward Secrecy

[Ben Laurie <[e-mail]>]

Hal Finney wrote:
> 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".

Agreed.

I have changed to this:

"Therefore when a public encryption key used for forward secrecy 
expires, an OpenPGP client MUST securely wipe the corresponding private 
key."

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

Since some client behaviour must be specified for PFS to work, I don't 
see that that is avoidable. However, I do agree that it should be kept 
to just that behaviour that is actually necessary. Secure deletion of 
private keys is necessary for PFS, and so that should remain. Retrieving 
(and decrypting) messages encrypted with that key before deleting is a 
good idea, but I agree is probably not something to be mandated by this 
draft.

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

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

I am more interested in the parts of the draft that require 
standardisation (such as marking [and transmitting] one-time keys). I 
would be more-or-less happy to remove the "advice" parts of the draft 
and find another venue for them, if that's what the WG wants.

Cheers,

ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff