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