negative security aspects of GAK compliance

I think there is a clear technical security case against the GAK
compliant packet, which I would like to see comments on from people
who think the political GAK compliant argument is not significant.

This ties in with using separate storage and communications keys, and
with the better security practice of having shorter lived
communications keys to provide forward secrecy from the point of
issuing new communication keys (could be once per month, once per
week, or once per message).

Once you acknowledge that it is more secure to have short lived
communication keys (which in my view it very clearly is), it should be
clear that by putting a GAK compliancy packet feature, or other second
recipient you are weakening the security because that is another door
into a message which you are trying to make forward secret -- you are
trying to ensure that after the fact, no-one, not even the recipient
can decrypt the old traffic.  (This is a very good way of ensuring
that third parties, like industrial espionage spies, people using
black mail or the Feds using rubber hoses, or supeonas or other legal
or extra legal forms of coercion, can't obtain from you keys to
decrypt it either, so they don't get plain text).  

The fact that the extra door into the message is outside the
recipients control means that his own security could be compromised by
sloppy practice on the part of that key holder.


This argues that if people are to insist on using the enforced second
recipient model for corporate snooping at all, they should for
security reasons be at least using short lived communications keys for
the GAK compliancy packet also.

Or, as I would argue, most secure of all is not using GAK compliancy
packets at all, but rather to use escrowed storage keys to retain
access to mail archives.  This is more secure because you don't keep
second doors into what should be a communication encrypted with as few
as possible (namely: one) transient communications key, with security
policy control being in the hands of the person who owns the key (the
recipient).

As I have pointed corporate access to stored email can be acheived
with similar amounts of snooping enforceability by having the PGP5.5
mail client store to an escrowed communications key after decryption,
or even to re-encrypt after decryption to a long term storage company
archive access bot within the LAN (with such encrypted messages
themselves being wrapped in an extra comms encryption envelope using
short term communications key if you like).


I would be interested to see anyone refute this security argument from
a security point of view.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

At 2:48 AM -0700 10/12/97, Adam Back wrote:

>Once you acknowledge that it is more secure to have short lived
>communication keys (which in my view it very clearly is), it should be
...


Just what are some of the issues with us getting D-H-type perfect forward
secrecy with something like e-mail? I assume this must be possible, of
course, as D-H is used in just these ways. (The Comsec 3DES phone I have
does this, of course.) (To repeat what has already been said, forward
secrecy means some of the important keys are not kept or stored, and so a
subpoena at some future time to produce the keys used in a communication is
pointless. Cf. Schneier for more.)

First and foremost as a requirement would be the need for a back-and-forth
communication, in a real-time or nearly real-time mode. This rules out
conventional e-mail with its long a variable latencies for delivery. (Not
to mention diverse clients and their inability to respond automatically!)

But IRC, chat rooms, Internet telephony, etc., are all common. With
latencies of ~seconds, or even less.

I picture conventional e-mail being replaced, for this application, with
this kind of system. Maybe D-H forward secrecy systems already exist....

Forward secrecy might be arrangable even with long-latency links...it seems
to me. (Through a series of links, compute and store the D-H parameters,
then use them with conventional e-mail for the "payload" message?)

--Tim May


The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Tim May <tcmay@got.net> writes:
> At 2:48 AM -0700 10/12/97, Adam Back wrote:
> 
> >Once you acknowledge that it is more secure to have short lived
> >communication keys (which in my view it very clearly is), it should be
> ...
>
> Just what are some of the issues with us getting D-H-type perfect forward
> secrecy with something like e-mail? I assume this must be possible, of
> course, as D-H is used in just these ways. (The Comsec 3DES phone I have
> does this, of course.) (To repeat what has already been said, forward
> secrecy means some of the important keys are not kept or stored, and so a
> subpoena at some future time to produce the keys used in a communication is
> pointless. Cf. Schneier for more.)
> 
> First and foremost as a requirement would be the need for a back-and-forth
> communication, in a real-time or nearly real-time mode. This rules out
> conventional e-mail with its long a variable latencies for delivery. (Not
> to mention diverse clients and their inability to respond automatically!)

It is difficult to have true interactive PFS for the reasons you
describe.

I did spend some time trying to work out a DH variant which could do
forward secrecy entirely non-interactively, but I couldn't find
functions with the desired properties.  If anyone is interested I can
repost the discussions of this, and my current note pad style
scribblings attempting to find said functions.  I am not convinced it
is impossible; perhaps some one will figure it out at some stage.  (I
have been having an intermittent on going discussion with Hal Finney
on this topic on and off list for the last year or so).

In the mean time what is entirely reasonable to do with email, with
pgp5.5 is to use short lived communications keys.  That is
communications keys which are planned to live for 1 week, say.

This would not result in immediate PFS as with interactive DH, but it
will be PFS at the end of the week.

You could do it more frequently if you wished.

As pgp 5.0 uses key servers directly from the mail client (and some
other clients do also), this all works out because you just publish
your new weekly communications key on the keyserver, and this
eliminates the need for interactive communications with your recipient
which true DH PFS requires.  In fact I think you could do this right
now, if you made it clear to others that your key has short expiry in
your .signature or whatever.  As I mentioned in another post David
Wagner currently does just this.


In my last post in the thread with subject:

	Subject: Re: negative security aspects of GAK compliance 

I think I have proved that you can't sensibly use pgp 5.5 with short
lived communications keys without also adding storage keys.  People
are acknowledging the logic that:

1. short term communications keys are more secure
2. it is a security mismatch to use long term CAK keys with short term
   communications keys
3. if you use short term CAK keys, you can't recover stored email for long
4. if you use short term communications keys the recipient you can't
   even read old email folders
5. therefore you need storage keys also
6. as a side effect PGP Inc's GAK compliant implementation of
   corporate access to stored email is fundamentally flawed, and has to
   be replaced with a different non GAK compliant method.

(I'm working on that last point, it does follow, and I think the logic
is sound).

> Forward secrecy might be arrangable even with long-latency links...it seems
> to me. (Through a series of links, compute and store the D-H parameters,
> then use them with conventional e-mail for the "payload" message?)

That is another way to do DH, and also is entirely reasonable.  You
could have this automatically for example if you were using one of the
IPSEC proposals which has forward secrecy at the IP transport layer.
If the systems which your mail went through to be delivered all used
IP level forward secrecy, the SMTP traffic would all be forward
secret.

However this form of forward secrecy has a different security focus;
keys are owned by machines rather than people, which means that it is
probably less secure.  For example you are relying on the security of
the recipients SMTP server.  

Also the last hop of the link, between the recipients POP3 mailbox,
and the users dial up machine is unsecured typically at the moment.
Some IPSEC security on this link (or SSH tunneling) also would be
possible then allowing that last hop to be secured.  However it is a
bit like GSM mobile phone encryption, the links are secured, but the
traffic goes in the clear through the base station.  The traffic ends
up in clear in the recipients ISPs POP3 mailbox.

Of course, you would actually encrypt the payload email also; the
setup is more secure than no forward secrecy, because with out
tampering with machines.

IPSEC with forward secrecy is a _really_ big win for our side, because
it automatically defeats government GAK plans; what use is GAK for
fishing expeditions if you can't get the ciphertext because all the
links are protected with forward secrecy.  It preempts GAKkers in an
area where they have little control: IETF standardisation processes.
The standards process I think refused to accept "for export" key
sizes, on the grounds that the standards should not be weakened by
political considerations.  With an internationally agreed, widely
deployed IPSEC standard with forward secrecy, the GAKkers will be
screwed because to change it will eventually mean cutting yourself off
from the internet, and there will be much software to unpublish, and
much inertia to overcome.

I presume it is for these types of reasons that John Gilmore and
others are enthused with the tracking the IPSEC standardisation
process, and in John's case in organsing his free S/WAN project to
produce a free linux IPSEC implementation.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

In <199710130116.CAA01032@server.test.net>, on 10/13/97 
   at 02, Adam Back <aba@dcs.ex.ac.uk> said:

>As pgp 5.0 uses key servers directly from the mail client (and some other
>clients do also), this all works out because you just publish your new
>weekly communications key on the keyserver, and this eliminates the need
>for interactive communications with your recipient which true DH PFS
>requires.  In fact I think you could do this right now, if you made it
>clear to others that your key has short expiry in your .signature or
>whatever.  As I mentioned in another post David Wagner currently does
>just this.

Adam,

Have you considered the logistical nightmare that this would cause?? I can
see that you are unaware of the precarious state the current PGP Public
Key Server Network is in. Right now it is getting by but this increase in
load would bring it all to a screeching halt. There have been suggestions
of moving key distributution to the DNS but I seriously doubt even it
would handle the traffic.

Also what happens to the "web of trust" in such a system of high key
turnover?

Exactly how much added security is provided by all of this?? While Forward
security via DH "may" be more secure is the added expense of implementing
such a system justified?? We all could switch to using OTP's for maximum
security but I doubt that few if any would justify the cost of such a
system.

PS: current PGP key format does have a field for key expiration. Until 5.0
it was only used in the Viacrypt version.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
---------------------------------------------------------------

William Geiger <whgiii@invweb.net> writes:
>    at 02, Adam Back <aba@dcs.ex.ac.uk> said:
> >As pgp 5.0 uses key servers directly from the mail client (and some other
> >clients do also), this all works out because you just publish your new
> >weekly communications key on the keyserver, and this eliminates the need
> >for interactive communications with your recipient which true DH PFS
> >requires.  
> 
> Have you considered the logistical nightmare that this would cause?? I can
> see that you are unaware of the precarious state the current PGP Public
> Key Server Network is in. 

The keyservers using pgp2.x as the key lookup engine are struggling
because the database code isn't very good.  But the experimental MIT
keyserver, and Tage Stabell-Kulo's key server code on the key server
in Norway fairly whistle through key lookups.  PGP Inc also is using
the better keysever code -- I think based on the one at MIT
implemented by Marc (surname escapes me right now).

> Right now it is getting by but this increase in load would bring it
> all to a screeching halt. 

It all depends on how up to date you are on keyserver performance
problems; perhaps you are more up to date than myself, perhaps not.

The answer I think which must come in any case is a distributed key
server system because the current 100% replication method seems
unlikely to scale to likely future demands, with or without forward
secrecy.  If your company holds keys for it's employees on it's openly
accessible key server, this distribution will be very similar to DNS,
and similarly scalable.

> There have been suggestions of moving key distributution to the DNS
> but I seriously doubt even it would handle the traffic.

I think this is taking it too far.  Have you considered how much
traffic DNS handles right now?  I would have thought it would be many
orders of magnitude more than forward secret email is going to cause.
Web traffic is the bulk of network communications, just imagine the
DNS lookups caused by 50 million netters clicking away. 

Bear in mind also hear that most users will probably be entirely
satisfied with a communications key update time of 1 week.  It is
probably mostly cypherpunks, or people with high value communications
to secure who would opt for more frequent key updates.

Bear in mind also that once the new key has been issued, you could
also release a deletion request for the previous one on the keyserver
in the form of a revocation certificate.

> Also what happens to the "web of trust" in such a system of high key
> turnover?

Nothing.  It is unaffected.  The WoT is only based on signature keys.
You personally certify your communication with your signature key.

> Exactly how much added security is provided by all of this?? 

Lots.  Consider: you are the average PGP user, you have one key
generated per year if you are lucky (probably more like once per life
time).  You are in a company, and the company has a heck of a time
persuading people not to use dumb passwords, or leave their passwords
on yellow sticky notes conveniently stuck to the corner of the
screen.

Scenario: the cleaner is bribed to switch on a machine with a supplied
boot floppy to put in the drive, and writes down the password on the
sticky note.

So, without forward secrecy the attacker now has all the traffic said
PGP user wrote in the life time of his encryption key.  What's that 1
years traffic?  (He'll have collected the ciphertext by eavesdropping
on SMTP traffic travelling over the internet).

With say once-a-day forward secrecy, the attacker gets nothing, no
previous communications, and no future communications.

Granted the attacker can install a replacement version of PGP to try
to get future traffic, but the company can run automated audit checks
of varying sophistications each morning to check if machines have been
switched on, and if files have been altered.  If tampering is
detected, or perhaps every morning you re-install the machine from
scratch remotely, as the MIT project did.  (Reckoned to be a human
resource efficient method of running networks -- got a problem with
your machine -- reload it, the lot no arguments).

> While Forward security via DH "may" be more secure is the added
> expense of implementing such a system justified??

Forward secrecy in a way is not something you need to argue about
adding or not as such, because in a sense you've already got it, built
in to pgp5.0.

To see what I mean you'd need to read Hal Finney's recent post on the
OpenPGP list, where he described how you could already achieve forward
secrecy using the fact that you've got a separate encryption key and
signature key.

You just set the encryption key to have a short expiry, and generate a
new one when it does expire.  You sign the encryption keys with your
signature key to transfer the WoT based trust to them.


The only extra functionality I am arguing for over what PGP5.0 already
has is some built in support for this type of usage, so that pgp will
manage the generation of new keys at the key expiry point
transparently.  That much as such doesn't need any modifications to
the current PGP standard.  It's an implementation issue.  Another
vendor could easily already implement this type of functionality.

Also I'm arguing for separate communications and storage keys, I think
this is almost essential once PGP starts to work with escrow schemes,
because there are similar arguments for separating storage and
communications keys as there were for creating separate signature and
encryption keys from the original single key.

> We all could switch to using OTP's for maximum security but I doubt
> that few if any would justify the cost of such a system.

Actually I hear Fred Piper was semi-seriously arguing for this ... his
argument went like this: mass storage is cheap and getting cheaper
fast; often the communications needed could be covered for years worth
of comms between to organisations by exchanged of a small read only
storage device.  Simple, and fool proof, etc.  But I digress.

> PS: current PGP key format does have a field for key expiration. Until 5.0
> it was only used in the Viacrypt version.

I know, convenient for implementing this type of feature.


I was also arguing for support for once per message forward secrecy.
You should like that one because I was arguing that this should be
done with out keyservers.  Just send the key to the person your
communicating in the email you would like a forward secret reply to.

I also personally prefer people to send me keys in email, because the
pay per second phone lines here at home mean that I tend want to avoid
doing too many online key lookups, so I think this would be an
individually useful feature.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

In <199710130438.FAA02474@server.test.net>, on 10/12/97 
   at 11, Adam Back <aba@dcs.ex.ac.uk> said:


>William Geiger <whgiii@invweb.net> writes:
>>    at 02, Adam Back <aba@dcs.ex.ac.uk> said:
>> >As pgp 5.0 uses key servers directly from the mail client (and some other
>> >clients do also), this all works out because you just publish your new
>> >weekly communications key on the keyserver, and this eliminates the need
>> >for interactive communications with your recipient which true DH PFS
>> >requires.  
>> 
>> Have you considered the logistical nightmare that this would cause?? I can
>> see that you are unaware of the precarious state the current PGP Public
>> Key Server Network is in. 

>The keyservers using pgp2.x as the key lookup engine are struggling
>because the database code isn't very good.  But the experimental MIT
>keyserver, and Tage Stabell-Kulo's key server code on the key server in
>Norway fairly whistle through key lookups.  PGP Inc also is using the
>better keysever code -- I think based on the one at MIT implemented by
>Marc (surname escapes me right now).

Actually the it is the new pgp5.0 servers that are having the problems.
The PGP Inc. server may be doing ok but they are not part of the Network
(they have cut-off their connection and are not sending out nor receiving
keyring updates to the other servers).

>> Right now it is getting by but this increase in load would bring it
>> all to a screeching halt. 

>It all depends on how up to date you are on keyserver performance
>problems; perhaps you are more up to date than myself, perhaps not.

>The answer I think which must come in any case is a distributed key
>server system because the current 100% replication method seems unlikely
>to scale to likely future demands, with or without forward secrecy.  If
>your company holds keys for it's employees on it's openly accessible key
>server, this distribution will be very similar to DNS, and similarly
>scalable.

I agree that the 100% replication can't last the number of keys and key
requests will become beyond what a PC based system can handle.

>> There have been suggestions of moving key distributution to the DNS
>> but I seriously doubt even it would handle the traffic.

>I think this is taking it too far.  Have you considered how much traffic
>DNS handles right now?  I would have thought it would be many orders of
>magnitude more than forward secret email is going to cause. Web traffic
>is the bulk of network communications, just imagine the DNS lookups
>caused by 50 million netters clicking away. 

Yes but everyone's Ip's aren't changing every week. It's not just a matter
of the multitude of requests that would be required in this systems as
everyone will need to update all their keys on a weekly basis but also the
DNS records will be having this turnover. the DNS system has enough
problems as it is let alone what would happen with the implementation of
forward secrecy would cause (my best guess that within a week or two the
whole thing would crash and burn).

>Bear in mind also hear that most users will probably be entirely
>satisfied with a communications key update time of 1 week.  It is
>probably mostly cypherpunks, or people with high value communications to
>secure who would opt for more frequent key updates.

Even a weekly turnover of all keys would be too much.

>Bear in mind also that once the new key has been issued, you could also
>release a deletion request for the previous one on the keyserver in the
>form of a revocation certificate.

You would have to otherwise you would run out of storage very quickly.

The best I can think of handleing the key distribution problem is to
attach a copy of your key to every correspondence and then have the client
automatically check and see if it has changed and update the keyring as
needed. If find both the automatic processing & sending the key with every
messages quite bothersome (these are PKS implementation issues that should
be covered in a different thread).

>> Also what happens to the "web of trust" in such a system of high key
>> turnover?

>Nothing.  It is unaffected.  The WoT is only based on signature keys. You
>personally certify your communication with your signature key.

>> Exactly how much added security is provided by all of this?? 

>Lots.  Consider: you are the average PGP user, you have one key generated
>per year if you are lucky (probably more like once per life time).  You
>are in a company, and the company has a heck of a time persuading people
>not to use dumb passwords, or leave their passwords on yellow sticky
>notes conveniently stuck to the corner of the screen.

>Scenario: the cleaner is bribed to switch on a machine with a supplied
>boot floppy to put in the drive, and writes down the password on the
>sticky note.

>So, without forward secrecy the attacker now has all the traffic said PGP
>user wrote in the life time of his encryption key.  What's that 1 years
>traffic?  (He'll have collected the ciphertext by eavesdropping on SMTP
>traffic travelling over the internet).

>With say once-a-day forward secrecy, the attacker gets nothing, no
>previous communications, and no future communications.

>Granted the attacker can install a replacement version of PGP to try to
>get future traffic, but the company can run automated audit checks of
>varying sophistications each morning to check if machines have been
>switched on, and if files have been altered.  If tampering is detected,
>or perhaps every morning you re-install the machine from scratch
>remotely, as the MIT project did.  (Reckoned to be a human resource
>efficient method of running networks -- got a problem with your machine
>-- reload it, the lot no arguments).

Well IMHO this scenario does not forward your cause much. If the physical
security is that bad (unrestricted access to equipment, weak passphrases,
Post-it-Notes, ...ect) then the information an attacker is looking for is
more than likely going to be available to him without messing with the PGP
keys. If the reverse is true and the physical security is strong the the
case for short-term separate keys is gone as the risk of exposure to a
long term key is greatly reduced.

>> While Forward security via DH "may" be more secure is the added
>> expense of implementing such a system justified??

>Forward secrecy in a way is not something you need to argue about adding
>or not as such, because in a sense you've already got it, built in to
>pgp5.0.

>To see what I mean you'd need to read Hal Finney's recent post on the
>OpenPGP list, where he described how you could already achieve forward
>secrecy using the fact that you've got a separate encryption key and
>signature key.

>You just set the encryption key to have a short expiry, and generate a
>new one when it does expire.  You sign the encryption keys with your
>signature key to transfer the WoT based trust to them.

>The only extra functionality I am arguing for over what PGP5.0 already
>has is some built in support for this type of usage, so that pgp will
>manage the generation of new keys at the key expiry point transparently. 
>That much as such doesn't need any modifications to the current PGP
>standard.  It's an implementation issue.  Another vendor could easily
>already implement this type of functionality.

I have some serious reservations of the security implications of frequent
changes to the keys. It has the potential for the user to disregard all
changes to the keys (think how quick the warning pop-ups in Netsacpe get
ignored and/or disabled by the user). The other possibility it to make the
key changes transparent to the user which I do not like at all for obvious
reasons (I do not see complete isolation of the user from the cryptosystem
as a Goodthing(TM) ).

>Also I'm arguing for separate communications and storage keys, I think
>this is almost essential once PGP starts to work with escrow schemes,
>because there are similar arguments for separating storage and
>communications keys as there were for creating separate signature and
>encryption keys from the original single key.

Well I have been thinking more on this. I still am not sold that separate
keys are needed but even if they are I am inclined to believe that PGP is
not the place for them. I am leaning towards the opinion that file
encryption should be handled by the files system along with other disk
security features. This seems more appropriate than having your e-mail
client doing individual file encryption.

>> We all could switch to using OTP's for maximum security but I doubt
>> that few if any would justify the cost of such a system.

>Actually I hear Fred Piper was semi-seriously arguing for this ... his
>argument went like this: mass storage is cheap and getting cheaper fast;
>often the communications needed could be covered for years worth of comms
>between to organisations by exchanged of a small read only storage
>device.  Simple, and fool proof, etc.  But I digress.

>> PS: current PGP key format does have a field for key expiration. Until 5.0
>> it was only used in the Viacrypt version.

>I know, convenient for implementing this type of feature.

>I was also arguing for support for once per message forward secrecy. You
>should like that one because I was arguing that this should be done with
>out keyservers.  Just send the key to the person your communicating in
>the email you would like a forward secret reply to.

>I also personally prefer people to send me keys in email, because the pay
>per second phone lines here at home mean that I tend want to avoid doing
>too many online key lookups, so I think this would be an individually
>useful feature.

I do my keylookups automatically durning the msg filtering process which
is done in parallel to the message Dl's. The outbound message lookups are
a little more time consuming but is compensated by fewer keys to look for
both because fewer messages on the outbound side and the use of key caches
on the client machine for the most used keys for sig verification and
encryption. Also logging of e-mail addresses that do not use PGP cuts down
on the number of lookups needed ( I only keep trusted keys in my pubring
all others are kept in the cache for performance reasons ).


-- 
---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
---------------------------------------------------------------

William Geiger <whgiii@invweb.net> writes:
> >I think this is taking it too far.  Have you considered how much traffic
> >DNS handles right now?  I would have thought it would be many orders of
> >magnitude more than forward secret email is going to cause. Web traffic
> >is the bulk of network communications, just imagine the DNS lookups
> >caused by 50 million netters clicking away. 
> 
> Yes but everyone's Ip's aren't changing every week. It's not just a matter
> of the multitude of requests that would be required in this systems as
> everyone will need to update all their keys on a weekly basis but also the
> DNS records will be having this turnover. the DNS system has enough
> problems as it is let alone what would happen with the implementation of
> forward secrecy would cause (my best guess that within a week or two the
> whole thing would crash and burn).

Your argument neglects that it was you who was arguing for DNS
distribution of keys.  I was never too keen on this idea.  Your
descriptions of the near breaking point reaffirms my dislike, though
I'm not sure I agree with your crash and burn predictions.  Mind, DNS
maintenance is not something I have a great deal of familiarity with.

My comparison was intended to be "implementing forward secrecy by
storing comms keys on keysevers using ad-hoc distribution of
distributed keyservers would cause orders of magnitude less traffic in
total than current DNS requests".  I think that sounds entirely
reasonable.

By ad-hoc distribution of key-servers I mean key servers which don't
have replication but rather store keys for some designated set of
users within a set of domains.  The DNS would be a good place to store
the resolving mechanism for deciding where the keyservers live.
Similar perhaps to the way you use a DNS MX record to find a mail
exchanger for the domain name you're trying to send to.  Use DNS
keyserver extension record to find keyserver IP address.

With that architecture, the whole thing sounds pretty scalable, and
adds negligble extra overhead to the DNS system.  Storing the keys
themselves directly into DNS is something people get interested in for
IPSEC, and for that application it seems more reasonable.

> >Bear in mind also that once the new key has been issued, you could also
> >release a deletion request for the previous one on the keyserver in the
> >form of a revocation certificate.
> 
> You would have to otherwise you would run out of storage very quickly.

Indeed!

> The best I can think of handleing the key distribution problem is to
> attach a copy of your key to every correspondence and then have the client
> automatically check and see if it has changed and update the keyring as
> needed. 

My thoughts also.  In fact for particularly short lived keys I have a
scheme worked out where key servers are not used at all.  I haven't
really described this scheme yet, as people seem to be raising enough
objections over the logical uses of current PGP functionality.

> If find both the automatic processing & sending the key with every
> messages quite bothersome (these are PKS implementation issues that
> should be covered in a different thread).

Well I thought it was a neat idea.  Perhaps that is because you have
the world view that every email recipient has a direct IP or at least
a dialup with flat rate connection charge, and also another reason I
thought it was neat was because I was considering it as a mechanism to
enable per message forward secrecy in a manner which I still haven't
explained in any detail.

> [protecting against users who store keys on sticky notes]
> 
> Well IMHO this scenario does not forward your cause much. If the physical
> security is that bad (unrestricted access to equipment, weak passphrases,
> Post-it-Notes, ...ect) then the information an attacker is looking for is
> more than likely going to be available to him without messing with the PGP
> keys. 

Yeah, well perhaps it wasn't that great an example.  However you can
see that extra security is being imparted even into this less than
ideal scenario.  These security problems are representative of the
problems some real life businesses face.  Most company employees do
not extract as much fun from the arcane fine points of best security
practice as we do.  They probably view security as an inconvenient
imposition, forcing them to learn things they don't want to know
about.

> If the reverse is true and the physical security is strong the the
> case for short-term separate keys is gone as the risk of exposure to
> a long term key is greatly reduced.

Ooh no.  It's not gone at all.  I think you are being a tad closed-
minded here.

If you have excellent security practice, you are still vulnerable to a
number of attacks which my proposal gives extra protection from:

1. being blackmailed, or having the password for your encryption key
   with 1 year expiry period rubber-hosed from you

2. having a keyboard sniffer installed by the Feds burgling your house
   whilst you are out.

3. having a virus installed by an attacker remotely or directly
   infecting your machine

With all 3 of these cases your security is blown wide open, despite
your 100 bit entropy pass-phrase and crypto-anarchist 'tude: "you'll
get my key when you pry it my cold dead fingers", and apparent
reasonable security precautions you will have blown your security.  If
your key had a 1 year expiry that might mean the Feds get up to 1
year's worth of the plaintext from the encrypted traffic they had been
meticulously collecting from their collaboration with invweb.net.

Now consider what happens to the above attacks when you have forward
secrecy:

1. blackmail/rubberhose .. it's kind of hard to not notice black mail
   or having passwords rubber hosed from you.  So as you have used my
   recommendations of the most paranoid forward secrecy setting (1 new
   key per message, sent in message) the attacker gets zip.  He gets
   nothing.  With a key update time of 1 day, your attacker gets up to
   one days plaintext, or with 1 week update up to 1 weeks comms.

2. keyboard sniffer .. presuming that you don't notice it, the
   attacker gets traffic going forward in time, but doesn't get old
   traffic

3. virus .. presuming that you don't notice it, the attacker gets
   traffic going forward in time, but doesn't get old traffic

I think that is a security advantage, wouldn't you agree?


There are quite a lot of precedents for using forward secrecy... for
example SSH, SSL, and some of the IPSEC protocols.  They aren't using
forward secrecy for phun, they're using it to increase security also.

Granted it's easier to do interactive forward secrecy with IP
connections than email, but forward secrecy is just another term which
describes something we are all already very familiar with: key expiry.

Consider why does PGP provide you with a mechanism to expire keys.
The reason is because it's acknowledged that it's a good idea to
change the keys now and then -- because this provides you with forward
secrecy -- the longer you use the same key the more the risk that it
is compromised accumulates, and the more value it will have to the
attacker because of the larger number of messages it is protecting.

So all I am really saying is that shorter key expiry times give you
more security... not that radical a statement I don't think.

> >That much as such doesn't need any modifications to the current PGP
> >standard.  It's an implementation issue.  Another vendor could easily
> >already implement this type of functionality.
> 
> I have some serious reservations of the security implications of frequent
> changes to the keys. It has the potential for the user to disregard all
> changes to the keys (think how quick the warning pop-ups in Netsacpe get
> ignored and/or disabled by the user). The other possibility it to make the
> key changes transparent to the user which I do not like at all for obvious
> reasons (I do not see complete isolation of the user from the cryptosystem
> as a Goodthing(TM) ).

Heh.  Well there is where we part company then, because I do think
hiding some parts of the crypto innards where this is appropriate is a
good thing.  I think the generation of new transient keys is one such
case.

You are already using this mechanism every day anyway: your SSL
enabled web browser will be setting up key exchanges using short lived
communications keys with secure web servers.  You do see notices when
you haven't agreed to trust this organisation before, but you will
observer that netscape asks you if you would like to trust this
organisation this session only, or for all further sessions.

What I am proposing is the same "for all further sessions", applied to
PGP.  I reckon it is more secure because you have the PGP WoT to help
guide you in your decisions, where as I currently find a lot of web
sites using uncertified server keys, and I'm not sure how much
security the very limited numbers of hierarchical server certifcate
issuers provide in practice.  I prefer the PGP WoT where I can get
face to face transfer of keys with people.  The trust is much more
immediate.

> >Also I'm arguing for separate communications and storage keys, I think
> >this is almost essential once PGP starts to work with escrow schemes,
> >because there are similar arguments for separating storage and
> >communications keys as there were for creating separate signature and
> >encryption keys from the original single key.
> 
> Well I have been thinking more on this. I still am not sold that separate
> keys are needed but even if they are I am inclined to believe that PGP is
> not the place for them. I am leaning towards the opinion that file
> encryption should be handled by the files system along with other disk
> security features. This seems more appropriate than having your e-mail
> client doing individual file encryption.

I agree with you there.  That is way the most appropriate place to put
storage encryption.  However (and this is my point also in another
form), if you were to do this, you would want to use a different key
than the one you use for protecting communications keys, because the
storage key may have different expiry requirements, and different
escrow requirements.

But... we have a circular dependency in our argument here, because
when I was arguing that you didn't need to encrypt the contents of
your mail folders 10 messages back or so, you jumped in and said that
you kept email communications encrypted in your mail folder.

I accepted your point, and countered that if you wanted to encrypt
messages in your mail folder, that you should use a storage key to do
so.  (Otherwise you couldn't sensibly make use of the expiry feature
on your communications key, as when your comms key expired, so would
your access to your mailbox!)

I agree with your above suggestion that it is actually easier, safer
etc, to use disk level encryption systems.  However I do think we have
to face that these are not that widely deployed yet, and that people
like yourself a few days back are correct in arguing that there may be
a case for building the functionality of encryption of stored traffic
in folders.  As PGP Inc is fielding integrated Mail clients which have
mail folders managed by the mail client, this gives us the case for
separate storage and communications keys.

This also gives a convenient place to put escrow -- you escrow the
storage key.

This implementation would completely avoid all arguments about PGP 5.5
being GAKware.

> >I also personally prefer people to send me keys in email, because the pay
> >per second phone lines here at home mean that I tend want to avoid doing
> >too many online key lookups, so I think this would be an individually
> >useful feature.
> 
> I do my keylookups automatically durning the msg filtering process which
> is done in parallel to the message Dl's. 

A clever optimisation to be sure.

> The outbound message lookups are a little more time consuming but is
> compensated by fewer keys to look for both because fewer messages on
> the outbound side and the use of key caches on the client machine
> for the most used keys for sig verification and encryption. 

I don't have a key cache, and my keyring is only 216k.  But I'm
curious about your automated process .. are you also checking all
signatures that you can by downloading the keys and checking out the
WoT for all received mailing list traffic etc?  This would cleary
result in a much bigger key ring.

> Also logging of e-mail addresses that do not use PGP cuts down on
> the number of lookups needed

Good optimisation.  It sounds really as if your OS/2 setup is more
advanced than a lot of other stuff around.

My setup is GNU emacs with Pat LoPresti's mailcrypt.el PGP and
remailer support lisp extension for emacs RMAIL and emacs GNUS
(newsreader).  I love it to bits.  It is totally excellent.  It
doesn't have a couple of your optimisations, but other than that it's
pretty good.  When you send messages, if you don't have the key it
will fetch it for you by trying keyservers, then finger user@domain.
It can snarf keys out of mail messages, paste keys into them, sign,
encrypt, check signatures, use remailers (type I and mixmaster).

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

    great idea, Tim. [total previous text follows my comments]

    paraphrase of Tim's basic suggestion:

        ...to consider DH session keying in real time or the latency of 
        maybe IRC, etc (several seconds?) to be able to dispose of the 
        session keys which makes subpoenas signifantly more difficult.

    Netscape's default mail setting is to handshake the destination
    server.  eg through sendmail. it will not return until it gets it
    or times out --then it tells you to try later and there is no
    way to file it easily --in other words, a problem to avoid.

    I am presuming the DH keys would be a wrapper on an already 
    encrypted message, although target machine can re-encrypt to
    recipient on a secure machine.

    1)  sendmail could be modified to do yet another function (essentially 
        describe in b); or,

    2)  I would prefer to run yet another daemon on every machine at a 
        specific port with the usual 'who are you' identify sequences, 
        preferably even changing it to call back to lesson spoofing, 
        despite the fact additional logic is required to kill denial of 
        service attacks.

        all that would be required would be the n number months/years
        wait for IETF to agree on a port and the protocol...

        the rest of it is pretty stock at the daemon side. the inside
        is where the fun begins.  If the message is already encrypted,
        (was inside DH wrapper) it can be delivered; otherwise:

        a)  if the machine is secure, the email can be delivered to the
            user's box

        b)  if the machine is the usual, then the daemon needs to use
            a local secret key to encode to the local user's public
            key to maintain an encrypted message.

    complicated? not from my perspective v. some of the other nightmares.

    using sendmail would be the fastest route to enablement, but it 
    probably would be years before sendmails were updated and aan old
    sendmail could just accept the call and hang one or the other without
    a resolution.

    the more we are wired, the more feasible it becomes.

    it would be nice if the usual store and forward of sendmail could
    be utilized. I think it would be very difficult to use sendmail itself,
    but it should be possible to use an independent daemon to perform
    the same function.  there would just be multiple DH sessions --much 
    like the cp remailer network; the few times I used mixmaster a few
    years ago, I sent an encrypted packet.
 ______________________________________________________________________
 "attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0 

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: No safety this side of the grave. Never was; never will be

iQCVAwUBNEJmJL04kQrCC2kFAQFyPQQAmDaB819149GNqJF1SZqhs2rxCAHADnlx
fMBgmBOhJi/bKnKafcEhMDnTWL82GtA9lpeVP5IkW9aQH8DCdQpoKbhmQ2lQZCEy
PHUpbDyVGDxOg5sCp9kDYImF0h6qVEtSDynxUVgAWiApmfCGGx5NoL4aAxDwg8gg
aOrxTePVFRw=
=xmTi
-----END PGP SIGNATURE-----


on or about 971012:1016 
    Tim May <tcmay@got.net> was purported to have 
    expostulated to perpetuate an opinion:

+At 2:48 AM -0700 10/12/97, Adam Back wrote:

+>Once you acknowledge that it is more secure to have short lived
+>communication keys (which in my view it very clearly is), it should be
+...

+Just what are some of the issues with us getting D-H-type perfect
+forward secrecy with something like e-mail? I assume this must be
+possible, of course, as D-H is used in just these ways. (The Comsec
+3DES phone I have does this, of course.) (To repeat what has already
+been said, forward secrecy means some of the important keys are not
+kept or stored, and so a subpoena at some future time to produce the
+keys used in a communication is pointless. Cf. Schneier for more.)

+First and foremost as a requirement would be the need for a
+back-and-forth communication, in a real-time or nearly real-time mode.
+This rules out conventional e-mail with its long a variable latencies
+for delivery. (Not to mention diverse clients and their inability to
+respond automatically!)

+But IRC, chat rooms, Internet telephony, etc., are all common. With
+latencies of ~seconds, or even less.

+I picture conventional e-mail being replaced, for this application,
+with this kind of system. Maybe D-H forward secrecy systems already
+exist....

+Forward secrecy might be arrangable even with long-latency links...it
+seems to me. (Through a series of links, compute and store the D-H
+parameters, then use them with conventional e-mail for the "payload"
+message?)

+--Tim May


+The Feds have shown their hand: they want a ban on domestic
+cryptography
+---------:---------:---------:---------:---------:---------:---------:----
+Timothy C. May              | Crypto Anarchy: encryption, digital
+money, ComSec 3DES:   408-728-0152 | anonymous networks, digital
+pseudonyms, zero W.A.S.T.E.: Corralitos, CA  | knowledge, reputations,
+information markets, Higher Power: 2^2,976,221   | black markets,
+collapse of governments. "National borders aren't even speed bumps on
+the information superhighway."

At 10:33 AM -0700 10/13/97, Attila T. Hun wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>    great idea, Tim. [total previous text follows my comments]
>
>    paraphrase of Tim's basic suggestion:
>
>        ...to consider DH session keying in real time or the latency of
>        maybe IRC, etc (several seconds?) to be able to dispose of the
>        session keys which makes subpoenas signifantly more difficult.
...

Just to clarify, I am far from the first to suggest this. In fact, my
ramblings were inspired by seeing Adam Back's comments (and he was of
course not the first either to discuss the advantages of perfect forward
secrecy for e-mail).

Probably my latest ramblings have a lot to do with the posts about the
Comsec secure phone. It, of course, offers perfect forward secrecy. To wit,
if the Feds demand that I produce the keys used for a phone call I had last
week with Hugh Daniel, for example, I can honestly shrug and say "You don't
seem to understand these things."

Lots of advantages to somehow applying this to e-mail. (As Lee Tien and
others have noted, the D-H protocol can be applied to e-mail. A point cited
by Diffie and Hellman about 20 years ago. The issue is integration with
mailers, latency times, etc.)

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Adam Back <aba@dcs.ex.ac.uk> wrote:
> As I have pointed corporate access to stored email can be acheived
> with similar amounts of snooping enforceability by having the PGP5.5
> mail client store to an escrowed communications key after decryption,
                                   ^^^^^^^^^^^^^^

Typo: that should be "storage key".

> I would be interested to see anyone refute this security argument from
> a security point of view.

And I am very interested to hear arguments against the logic of that
message.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`