Subject: Re: Forward secrecy

From: [email-masked]
Date: Thu, 3 Aug 2000 18:00:12 -0700

A comment on
http://www.ietf.org/internet-drafts/draft-brown-pgp-pfs-00.txt,
"Forward Secrecy Extensions for OpenPGP".

The ideas here are good, but I object to the inclusion of the one time
pad as a new cryptographic method for OpenPGP.

Although OTPs can provide forward secrecy, this is not their main purpose
(which is to provide absolute secrecy).  And to use them primarily for
this purpose requires some care which the proposed mechanism doesn't
really address.

In particular, there is nothing in the proposal for distinguishing
multiple OTPs, or for indicating which ones should be used for a given
decryption.  Also, there is no mechanism for selectively erasing just
part of a given OTP.  The assumption seems to be that there is one OTP,
and it is used to decrypt one message, then it is deleted.  Given the
tremendous difficulty of distributing a OTP, this is not a practical
mode of operation.

But rather than fixing this up by providing OTP identifiers, storage
modes, ways to keep track of which parts of a OTP should be deleted,
etc., I think this whole section should be removed.  It goes too far
beyond the claimed scope of the document.  Adding a OTP is a whole new
area of functionality for OTP.  It doesn't belong in a document like
this, IMO.

There are some other ideas you might want to consider.

One is what has recently been discussed on the ukcrypto list, which is
to provide a mechanism in the client to surrender selected session keys
rather than public keys, under court order.  This provides a minimal
way of complying with the new UK laws.

The document proposes that when you export a private key in the clear,
it should be automatically revoked with an appropriate reason-for-
revocation flag set.  This is reasonable, although it is obviously easy
to force someone to give you their key without triggering this mechanism,
by having them export it encrypted but tell you the passphrase.

Another idea along these lines is to have a mode to export the private
part of only the subkeys, or perhaps a single subkey, while exporting
only the public part of the top level signature key.

Perhaps rather than triggering a revocation, it could set the bit in the
self-signature key flags meaning "the private component of this key
may be in the possession of more than one person".  Then you'd want to
have the clients display keys with this bit set in some special way.

Another idea, which would be much harder to specify clearly, was
something that PRZ proposed to me way back in 1992.  Similar to the
one-use decryption keys, he proposed that communicating parties cache a
session key to be used over a series of messages, updating it for each
message transfer.  You could get forward secrecy by doing something like
new_key = hash(old_key), with appropriate precautions.  This would be a
lighter weight mechanism than the one-use decryption keys, but it would
be more of a change to the OpenPGP standard.

Hal

---

From: Ian Brown <[email-masked]>
Date: Fri, 04 Aug 2000 10:48:30 +0100

Hal,

Thanks for the comments :)

We did include mechanisms for specifying the one-time pad to be used to
decrypt a given message:
--
4.2 One-time pad reference
...
     - A four-octet date when the referenced one-time pad was created.

     - A four-octet offset specifying the first octet in the referenced
       pad that should be used as key.
--
ie the creation time was meant to be a pseudo-ID.

But I am quite happy to take out the OTP section if that's what people
want: if anyone later feels they need it, they would be welcome to
cannabalise our text as the starting point for a new RFC. What are other
people's thoughts?

> way of complying with the new UK laws.

I have added the following paragraph to the "Key Surrender" section:

"The least compromising key required MUST be the one surrendered. The
session key used to encrypt an individual message will often be sufficient.
Otherwise, a subkey should be surrendered before a long-term top-level key.
Signature keys should not be surrendered unless absolutely necessary."

> be more of a change to the OpenPGP standard.

This is nice, but does need a reasonable amount of work to specify. If
people feel this would be valuable, we could discuss it further.

Ian :)