Subject: Forward secrecy

From: Ian Brown <[email-masked]>
Date: Wed, 05 Jul 2000 11:55:43 +0100

I don't know how much everyone has seen of the UK government's current
attempt to legislate for access to keys, but despite extreme opposition
they seem set to push through powers for "information disclosure" orders
that allow *any public authority* to demand keys (on pain of two years'
imprisonment) and impose a gagging order that prevents you telling anyone
but your lawyer (or go to jail for five years).

Adam Back, Ben Laurie and I have been working on a draft that would allow
OpenPGP software to minimise the damage such a notice could cause to a PGP
user. It specifies mechanisms for using short-lifetime and one-time keys to
limit the amount of information that becomes vulnerable after key
compromise.

John Noerenberg suggested we publish it as an informational RFC. We would
be grateful for feedback from this group before we take that step.

The current version is at
http://www.cs.ucl.ac.uk/staff/I.Brown/openpgp-pfs.txt

Thanks!

Ian :)

---

From: [email-masked]
Date: Thu, 06 Jul 2000 16:49:29 +0900

From: Ian Brown <[email-masked]>
Subject: Forward secrecy
Date: Wed, 05 Jul 2000 11:55:43 +0100
Message-ID: <[email-masked]>

> be grateful for feedback from this group before we take that step.

here are some comments:

  -this document seems to be focused on the use of openpgp for mail in
   particular.  is there anything to be said for other uses?  (e.g. 
   openpgp key usage in ssh)

  -section 2.1 says:

    Key distribution can be eased by submitting new keys to key
    servers, where they will be available for other users to retrieve.
    Submission and retrieval SHOULD be performed automatically by
    software. Expired public encryption keys MUST be deleted by users
    and keyservers to remove information on old key pairs. Expired
    private encryption keys MUST be securely deleted to prevent later
    compromise.  

   i think whether the key distribution should happen automatically
   should be a matter of policy.  some of us have keypairs of which the
   public portion is not really made widely public, nor do we want it to
   be made so.  perhaps such relevant policy can be expressed in the key
   and implementations could interpret it appropriately.

   i wonder how much success one will have w/ convincing the
   keyserver folks that they should delete expired public keys.  i would
   like the ability to be able to tell a keyserver to remove a public key
   for which i have the corresponding secret key (or may be even the
   typically existing email address), but i don't get the impression that
   it's a popular idea thing among implementors.  

  -section 2.2 says:

    Before an OpenPGP client exports a private key as plaintext, the
    associated public key MUST be revoked and redistributed.

   i think i see a good reason for this, but i wonder whether it is
   practical.  doesn't redistribution of the key require net
   access? 

   to implement this correctly, when requested to export
   a private key as plaintext, the implementation first revokes the key,
   then redistributes the key by sending it to the keyservers, and
   then exports the private key (perhaps after confirming that the
   redistribution has been successful).  if it cannot contact a keyserver
   (or verify that redistribution was successful), a correct
   implementation would not export the private key as plaintext,
   i presume.  perhaps i'm nitpicking...

   also, which takes precedence, the deletion of expired keys from
   keyservers or the distribution of revoked keys?  is this also a matter
   of policy that could be reflected in the key?

  -how about saying "attackers" instead of "hackers" in section 6?

  -how about some "secure deletion" references in the references section?

off-topic: how about you guys write an informational rfc that suggests
best practice methods for email message header confidentiality ;-)

---

From: Ben Laurie <[email-masked]>
Date: Thu, 06 Jul 2000 19:52:01 +0100

>    openpgp key usage in ssh)

We should certainly extend it to cover other uses. Good idea.

>    and implementations could interpret it appropriately.

It is a SHOULD rather than a MUST so a compliant implementation can
choose to not do it. However, we should probably make a specific note to
that effect. OTOH, I notice that one of the changes I intended to make
has not been: that is that it is not necessary to delete public keys,
only private ones. In fact, expired public keys may be required to check
the validity of (old) revocations.

>    it's a popular idea thing among implementors.

I have exchanged some mails with (some of) the keyserver folks, and the
widespread use of short-lifetime encryption only keys will kill the
keyservers if they do not expire them. So, I think they may well wish to
do it.

>    i presume.  perhaps i'm nitpicking...

I guess it needs addressing.

>   -how about saying "attackers" instead of "hackers" in section 6?

Sure.

>   -how about some "secure deletion" references in the references section?

For example?

> best practice methods for email message header confidentiality ;-)

I thought someone else was doing that already?

Cheers,

Ben.

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

Coming to ApacheCon Europe 2000? http://apachecon.com/

---

From: Ian BROWN <[email-masked]>
Date: Fri, 07 Jul 2000 17:02:55 +0100

Thanks for the comments :)

>    openpgp key usage in ssh)

I have included a new paragraph on the use ofOpenPGP keys with
network/transport layer security services:

    Where OpenPGP keys are used in protocols such as IPSEC [2] or TLS
    [9], they SHOULD NOT be used to encrypt keying material that can
    later be decrypted if they are compromised. Ideally, they SHOULD be
    used only to authenticate a forward-secret key negotiation
    protocol such as Diffie-Hellman [3]. At the least, new short-
    lifetime key pairs SHOULD be generated for key encryption use.

Sound sensible?

>    and implementations could interpret it appropriately.

I have changed the paragraph as follows:

    Key distribution can be eased by submitting new keys to key
    servers, where they will be available for other users to retrieve.
    Submission and retrieval of generally-available public keys (those
    self-signed with an exportable signature) SHOULD be performed
    automatically by software. Expired public encryption keys MUST be
    deleted by users and keyservers to remove information on old key
    pairs. Expired private encryption keys MUST be securely deleted to
    prevent later compromise.

>   -how about some "secure deletion" references in the references section?

I have something by Markus Jakobsson that can go in: we could also mention the 
relevant DoD requirements.

The "revoke and redistribute" requirement on surrendered keys is tricky: as 
you say, what happens if the client can't contact a keyserver? I suppose the 
weak answer is that as more and more people get always-on DSL/cable modem 
connections, and any one of the keyservers can be contacted, this shouldn't 
happen often (as long as the police don't catch on). But I suppose we could
say something like if keyservers are unavailable, the client may queue the
revocation for later distribution then export the key.

>    of policy that could be reflected in the key?

We were thinking of revoked and expired keys as separate categories. 
Keyservers certainly shouldn't delete revoked keys *until their expiry date is 
reached* -- at which point they shouldn't be used anyway.

Ian :)

---

From: Will Price <[email-masked]>
Date: Fri, 07 Jul 2000 15:34:54 -0700

IPsec is spelled "IPsec".  Not "IPSEC".

-- 

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

---

From: Ian BROWN <[email-masked]>
Date: Sat, 08 Jul 2000 12:07:57 +0100

Will,

>IPsec is spelled "IPsec".  Not "IPSEC".

grepping through the messages in my ipsec WG folder, I find:

IPSEC 113 times
IPsec 104 times
IPSec 38 times

I also see that the IETF Working Group description begins:

>Rapid advances in communication technology have
>accentuated the need for security in the Internet.
>The IP Security Protocol Working Group (IPSEC)
>will develop mechanisms to protect client
>protocols of IP. A security protocol in the
>network layer will be developed to provide
>cryptographic security services that will flexibly
>support combinations of authentication, integrity,
>access control, and confidentiality. 

Ian.

---

From: Will Price <[email-masked]>
Date: Sat, 08 Jul 2000 04:40:31 -0700

Yes, it's a common error, but there is in fact only one correct way: IPsec.

See RFC 2401 or the working group discussion on this topic for more information.

--

---

From: Adam Back <[email-masked]>
Date: Sun, 16 Jul 2000 23:47:30 -0500

Section 3 describes one-time keys, that are sent with messages to
allow a the recipient to reply with immediate forward secrecy
(immediately after receipt).

I wonder if we could use a one-time key server to avoid the need for
interactive use of email (need a reply from the recipient to get a key
to reply to).

Lets say we add a new function to keyservers which is that you submit
a whole bunch of keys, and it hands them out on request, and deletes
them after they've been received.

I guess there's a pretty easy DoS there -- someone just goes and
repeatedly downloads all available keys, to deny others the ability to
obtain one-time keys.

There might be some weak approaches to resist this DoS (eg refuse to
provide more than one one-time key per time period to the same IP
address), but they are just that -- weak.

Adam