Why Corporate Message Recovery isn't Key Escrow
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A number of people have asserted that the Corporate Message Recovery feature is key escrow. From where I sit, the difference is easy to see. My definition of "key escrow" is that another person or organization keeps a copy of the user's secret key. Here's an example, based on actual customers who use key escrow to manage their data: This corporation uses PGP for a number of things. Email, engineering plans, CAD drawings, and so on. They've done so at least since the days when we were Viacrypt, and I believe they even used PGP 2.x. When an employee arrives at this company, they create a key pair for the new employee, hand it to them on a floppy, keeping a duplicate floppy with the keypair on it, which they toss into a safe. Literally. This is key escrow. They do this because they can't afford to lose their files and messages. Their policies require them to keep the secret keys, as if they were the same as keys to offices or file cabinets. I don't know about you, but I'm appalled. Nonetheless, they're our customers. In spite of inheriting them, we have a responsibility as businesspeople to at least listen to their concerns. - From our standpoint, the issue gets even touchier. They don't like what they're doing, and they want us to give them a better way to manage their data. Does anyone really believe that only moral response is to flinch and turn away? I'd like to be in a situation where I didn't have to deal with this. Wanna trade positions? I'll sit over there and cluck my tongue about how adding an extra recipient weakens security while you figure out how to help these folks out of the mess they're in. While you're at it, I'll pen a few lines about how giving clean needles to addicts undermines society, and handing out condoms encourages kids to have sex. Trust me, it's less nerve-wracking than what we have to do to solve this problem, which involves running through hypothetical scenario after hypothetical scenario, balancing the user's privacy against the organizations property rights, the privacy and property rights of one organization against that of another, and so on. Corporate Message Recovery isn't key escrow for a number of reasons. First, it doesn't involve keeping a copy the end-user's secret key. I hope that's obvious now. Second, the system behaves very differently. With a key escrow system, there is a superb McGuffin (which is what Alfred Hitchcock called the crux of a mystery, like the falcon in The Maltese Falcon) - it's the safe. Break into the safe, or lend its contents out, and all Hell breaks loose. Whoever has those keys (which easily fit on a single Zip disk) has the company at its mercy. They can decrypt or sign anything they care to. There is a great thriller to be written here. It isn't so with a CMRK. The worst possible way to use the feature is to have a single, company-wide CMRK. If that gets lost, the thriller you can write isn't nearly as interesting. Yup, you can steal any of the plans, read all the mail, and so on. That's bad. It's deplorable, actually. But it isn't a difference that makes no difference. At least there isn't a gang of keys out there that can sign anything with anyone's ID. This is not the only way to use Corporate Message Recovery, it's just the worst way. Remember, it's just a notation in the self-signature that states, "When you encrypt to me, encrypt to X." That's any X. You can have a different CMRK for every department, every workgroup, or even every user. A sophisticated policy might be that every user sets their supervisor's key to be their CMRK. Another is that everyone in Department X sets their office mate, or lab partner, or other person. You can have anything that suits your group, from Recovery Central, to Recovery Hierarchy, to Recovery Buddy System. The significant improvement that PGP's web of trust has over a traditional hierarchical system is that you can set up a top-down system for validity, but you don't have to (and in our opinion, shouldn't). Analogously, the significant improvement that Corporate Message Recovery has over key escrow is that you can tailor a recovery system to your needs (including and especially deciding it's not for you). Jon -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQA/AwUBND6j8H35wubxKSepEQI58gCfQuiMZCyfe7cD1F2nNgFtluQqGXMAoJUh yHFMApAlDjzwRTCspBi7p9t3 =a2Zo -----END PGP SIGNATURE----- ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)
-----BEGIN PGP SIGNED MESSAGE----- At 02:12 AM 10/11/97 +0100, Adam Back wrote:
You should have 3 types of key:
1. signature keys 2. transient encryption keys 3. storage keys
The signature keys you never escrow. You certify. If something goes wrong you re-issue, release revocation cert, and re-certificate.
The transient encryption keys are for communications, you delete them immediately after use. Yes I'm talking forward secrecy here. If you don't like forward secrecy, well at least don't escrow the encryption keys.
Huh? Okay, PGP uses IDEA for transit keys. These are encrypted to two different PGP public keys. These are only used once. (Well, you make that assumption, but with even a decent PRNG it's a reasonably safe assumption) The signature keys (in the proposed method) are the PGP keys (either RSA or DH, it's not important) are the personal keypairs of each person. The company doesn't keep a copy of these. They can sign with this in an unforgable manner. (Well, in practice I doubt that's true, because I've seen very few places that have even mild local-workstation security, but that's besides the point) Is there a problem here? - From the description Jon gave of the system, you can designate anyone as the other key-id to encrypt to in your signature block. (Or whatever that part of the key is called). The guy in the next cube, your boss, one company-wide key, etc. So yes, in theory this could be used to implement GAK. Supposedly in the version of PGP in use it's trivial to remove this extra recipient from the list of encryption keys. It's not even needed if you don't have that key on your ring. (From what Jon said) When you compalin about use of storage keys/communication keys your clouding the issue. The storage keys can be (and probably are in some cases) simply pgp encrypted files, as if they were in transit. I tend to encrypt some files on my hard drive with pgp, by encrypting to myself and signing so that onyl I can decrypt them, and I've got record that I did create the archive. I can see this being done in a company to simplify shared storage usage without security problems. Using the multiple recipient option your recovery key-id can be used to decrypt these files. Of course, if they're modified, they can't be resigned, so you'd know, but... This is a *simple* solution that eliminates problems with encrypting hard drives, etc. Where is the problem with this system? This is software that (according to Jon's claim) at least one company has decided they need for their security, and it keeps the number of pass phrases that employees need to memorize at one - their PGP key.
Storage keys you make damn sure you can recover. You escrow these for real. Company safe sounds about right. Secret splitting could be nice also.
Why not just encrypt it to yourself with PGP? Isn't that simpler? Add a recipient of the recovery id. Boss, coworker, person's key in another division, whatever. Everybody gets different storage keys. No need to worry about accidently compromising one of the storage keys (IDEA symmetric keys, of course). You then just need to keep the secret halfs of the public keys secure. Not a big deal if you have the rest of the system working.
You shouldn't be recovering transient messages, you should be recovering stored data.
What the hell is the difference? Speed of recovery? Give an example of the difference between what he's doing and what you would propose. Otherwise you're just rejecting this system blindly. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBND/agDc3ytqHnNyNAQExygP/fjl70OenYyTLc86OgFNZf5fkM+b3RUxw WFsYNme/thDSdsnmfTCTTqE63b3ZRoj/mR0jjb4aloXw83TxWuEY9j9sQql8yTBt SoRQAxPnP33bWlCTbQrOBPFvMw2lyfCrL307mXnfBpnW3h0cngRxjfu7IBBBPzVF /5TzMK47WBY= =RLoK -----END PGP SIGNATURE----- ----------------------------------------------------------------------- Ryan Anderson - <Pug Majere> "Who knows, even the horse might sing" Wayne State University - CULMA "May you live in interesting times.." randerso@ece.eng.wayne.edu PGP Fingerprint - 7E 8E C6 54 96 AC D9 57 E4 F8 AE 9C 10 7E 78 C9 -----------------------------------------------------------------------
Ryan Anderson <randerso@ece.eng.wayne.edu> writes on cpunks:
Adam Back <aba@dcs.ex.ac.uk> writes:
You should have 3 types of key:
1. signature keys 2. transient encryption keys 3. storage keys
The transient encryption keys are for communications, you delete them immediately after use. Yes I'm talking forward secrecy here. If you don't like forward secrecy, well at least don't escrow the encryption keys.
Huh? Okay, PGP uses IDEA for transit keys. These are encrypted to two different PGP public keys. [...] These are only used once.
The security principle I am referring to is that by doing as PGP currently does, and using encryption keys in place of separate communications and storage keys you are exposing your past traffic to undue risk. I am not at all referring to symmetric keys, because the fact that they are randomly generated and used once doesn't protect them from recovery via the compromise of your long encryption key and your attackers copy of your encrypted communications. The reason for randomly generating IDEA session keys is a separate one. The argument for having separate storage and communication keys is a similar one to the now accepted argument that it is a good idea to have separate signature and encryption keys. The obvious advantage of separating signature keys from encryption keys (introduced in pgp5) is that if you escrow keys you don't want to escrow signature keys as all this enables is forgery.
The signature keys (in the proposed method) are the PGP keys (either RSA or DH, it's not important) are the personal keypairs of each person. The company doesn't keep a copy of these. They can sign with this in an unforgable manner.
Is there a problem here?
No. I wasn't discussing signature keys.
- From the description Jon gave of the system, you can designate anyone as the other key-id to encrypt to in your signature block. (Or whatever that part of the key is called). The guy in the next cube, your boss, one company-wide key, etc.
Yes. That's half of the story. The other half of the story is that PGP went ahead and implemented a SMTP snoopware policy enforcer which could just as easily be used to enforce GAK.
So yes, in theory this could be used to implement GAK. Supposedly in the version of PGP in use it's trivial to remove this extra recipient from the list of encryption keys.
I'm not sure that the fact that the pgp5.0 client doesn't attempt to force you to use the GAK compliancy key adds much to my comfort level that the whole thing won't end up being used for mandatory GAK. My scepticism is derived from the fact that the enforcement of the GAK compliancy key is provided by another marvelous PGP Inc big brother innovation: the SMTP snoopware/GAK compliancy policy enforcement app. The argument doesn't really become apparent until you consider the effects of lots of people (say 80% of companies) using PGP's GAK compliancy enforcement. A few more thin edge of the wedge moves on the part of the USG GAK proponents (eg deputising service providers as GAK compliancy enforcers, something which has already been discussed in the past with the Clipper series), and you will suddenly be unable to exchange mail with anyone without using GAK. Sure you have a "choice", you can send email to people that will bounce 100% of the time, whoever you send to due to lack of GAK compliance field. (Except for perhaps a few die hard cypherpunks).
It's not even needed if you don't have that key on your ring. (From what Jon said)
I'm not sure what you mean here.
When you compalin about use of storage keys/communication keys your clouding the issue.
It might appear complex, but actually adding the distinction between communications and storage keys greatly simplifies things, and it allows you to make more appropriate security decisions about key life times, and escrow. It also allows you to implement the message snooping function in a more secure way, and with less big brotherish overtones. Using separate storage keys allows you to: - escrow storage keys within your company without including GAKware compliancy - discard communications keys often (by giving them short life-spans) which greatly enhances your security
The storage keys can be (and probably are in some cases) simply pgp encrypted files, as if they were in transit.
Storage keys could be symmetric keys if they are for your own use only, or you could escrow them if you want to share access, or your company wants the extra assurance of data availability that storage key escrow brings. There might be some security advantages to using symmetric keys even. (Public key sizes are a faster sliding and more uncertain target than symmetric key sizes.
I tend to encrypt some files on my hard drive with pgp, by encrypting to myself and signing so that onyl I can decrypt them, and I've got record that I did create the archive.
You can sign and encrypt with symmetric keys also. "pgp -cs." Quite a useful combination. I used to do the opposite of what you do... I used to use pgp -cs, because I explicitly didn't want the public key baggage, and danger that 1024 bit keys might be readable in 10-20 years, the then maximum key size.
I can see this being done in a company to simplify shared storage usage without security problems. Using the multiple recipient option your recovery key-id can be used to decrypt these files. Of course, if they're modified, they can't be resigned, so you'd know, but...
It's probably simpler to just escrow storage keys. That is just give management a copy to put in the fire proof safe. Or secret split or whatever. You could use multiple crypto recipient if you wanted to -- it's basically just another way of acheiving the same thing. There is one (quite practical) reason, however, to use symmetric storage keys. Speed. If you're encrypting lots of files (perhaps using an encrypted parition driver such as Peter Gutmann's SFS), you won't have time to encrypt to public keys, never mind multiple public keys. If the company keeps it's employee's storage keys in escrow, the fact that you're using a symmetric key works fine.
This is a *simple* solution that eliminates problems with encrypting hard drives, etc.
I don't see that it's any more difficult to do as I outline above, which is better security practice in any case.
Where is the problem with this system? This is software that (according to Jon's claim) at least one company has decided they need for their security, and it keeps the number of pass phrases that employees need to memorize at one - their PGP key.
Don't confuse key functionality with user ergonomics. PGP or other vendors could easily implement a unified interface to a secured private key database containing all of your persistent private keys. You need only have one key. Or perhaps no keys -- in a secured environment, or with keys stored on smart cards.
Storage keys you make damn sure you can recover. You escrow these for real. Company safe sounds about right. Secret splitting could be nice also.
Why not just encrypt it to yourself with PGP? Isn't that simpler? Add a recipient of the recovery id. Boss, coworker, person's key in another division, whatever. Everybody gets different storage keys. No need to worry about accidently compromising one of the storage keys (IDEA symmetric keys, of course). You then just need to keep the secret halfs of the public keys secure. Not a big deal if you have the rest of the system working.
I'm not really fussy beyond the fact that it will be less efficient in space (extra public key packets would be significant for a disk block level partition encrypter), and the performance issues with using public key crypto to encrypt lots of files to multiple people.
You shouldn't be recovering transient messages, you should be recovering stored data.
What the hell is the difference? Speed of recovery?
Nope speed of recovery is not the issue.
Give an example of the difference between what he's doing and what you would propose. Otherwise you're just rejecting this system blindly.
I'm sure I've given these reasons earlier in the thread, but I'll summarise them again: 1. It is more secure to use short lived communications keys because communications keys are more sensitive than storage keys. This is because with communications your attacker has copies of your ciphertext as you're sending it over an insecure open communications medium. Your storage data is on your hard disk, possibly in a secured environment. 2. People shouldn't be able to recover the data from communications because for security reasons it should be encrypted with transient communication keys. You are purposelly securely wiping the key after some period. Keeping extra doors into the communication weakensn this protection. 3. given that secured communications are now defined as transient in nature, for security reaons: the natural way to archive such communicated data is to re-encrypt it for a storage key. 4. people don't really want access after the fact to their transient communications, they want access to their archived email. 5. you can still implement corporate snooping, and I acknowledge that businesses have a right to do this (though personally I may not choose to work for a company which does this). But you can implement message snooping, by implementing key escrow of the storage key used to secure your email archives. To enforce this to the extent that you can, you build in automatic archiving in a way which is hard to defeat in the mail client to decrypt communication with the comms key, and then re-encrypt with the escrowed storage key. 6. Given the marked difference in life time, security requirements, and data availability requirements between stored data and transient communications keys is it any wonder that you can achieve a more flexible, more secure system by separating functionality of your keys -- it really is a very similar argument as to the argument over why you should have separate storage and communications keys. 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----- At 11:31 PM 10/11/97 +0100, Adam Back wrote:
to exchange mail with anyone without using GAK. Sure you have a "choice", you can send email to people that will bounce 100% of the time, whoever you send to due to lack of GAK compliance field. (Except for perhaps a few die hard cypherpunks).
My reading of Jon's post was that the SMTP policy enforcer only worked for outgoing messages. Perhaps that's wrong, but that needs to be double- checked. See below as well...
It's not even needed if you don't have that key on your ring. (From what Jon said)
I'm not sure what you mean here.
The snooping key. If it doesn't exist on *my* keyring. (Say I have your key, but not the key designate as your snooping key...) [BTW: Forgive the English, I'm tired and speaking in choppy sentences] If I have your key, but not the other key that I'm also supposed to encrypt to, PGP (whichever versions, I'm not entirely sure how the feature set breaks down, but I believe this applies to all versions of 5.x) will not even mention that there was another key it would've have offered to encrypt to.
When you compalin about use of storage keys/communication keys your clouding the issue.
It might appear complex, but actually adding the distinction between communications and storage keys greatly simplifies things, and it allows you to make more appropriate security decisions about key life times, and escrow. It also allows you to implement the message snooping function in a more secure way, and with less big brotherish overtones.
Using separate storage keys allows you to:
- escrow storage keys within your company without including GAKware compliancy
- discard communications keys often (by giving them short life-spans) which greatly enhances your security
Greatly complicating the "web of trust" method, but.. You can only chain signatures so far before you run into problems, and getting people to continuosly recertify could be a major pain, but I can see the point you are making. It got clearer.
The storage keys can be (and probably are in some cases) simply pgp encrypted files, as if they were in transit.
Storage keys could be symmetric keys if they are for your own use only, or you could escrow them if you want to share access, or your company wants the extra assurance of data availability that storage key escrow brings. There might be some security advantages to using symmetric keys even. (Public key sizes are a faster sliding and more uncertain target than symmetric key sizes.
Well, at least with RSA keys, I believe the memory requirements to handle current factoring algorithms are quite untenable for 2048 bit keys. I think 768 is out of the range of current systems. I think this came up on the RC5 (Bovine) mailing list, and the figures for the required server was something absolutely ridiculous. To distribute the job using the more efficient algorithm required machines with 128 meg of ram, but the slower one was a bit more doable. In short, I don't think 2048 RSA keys are reasonable target in the forseeable future. [Remember, Moore's law is only applicable for another 12 years or so. Then quantum mechanics starts to be a serious problems, and electrons start switching channels in the chips.] But this is a bit of a wandering topic now. Let me continue...
You can sign and encrypt with symmetric keys also. "pgp -cs." Quite a useful combination.
Hmm.. I must've missed that.
I used to do the opposite of what you do... I used to use pgp -cs, because I explicitly didn't want the public key baggage, and danger that 1024 bit keys might be readable in 10-20 years, the then maximum key size.
Well, I wasn't really encrypting anything I really cared about. It was backups of autoexec.bats and config.syss, I just wanted another copy that I *knew* when it was made, it wouldn't get overwritten, and it wouldn't get modified without me knowing. And I needed something to use PGP for, so... In all honesty, the public key baggage is 512 bytes ( I think, possibly bits. I've forgotten now ) Quite insignificant if you're dealing with CAD drawings. The added benefit of reducing passphrase uses is quite significant (with current PGP versions, the database of keys is a better idea actually). Possibly more portable across a range of users as well.
I can see this being done in a company to simplify shared storage usage without security problems. Using the multiple recipient option your recovery key-id can be used to decrypt these files. Of course, if they're modified, they can't be resigned, so you'd know, but...
It's probably simpler to just escrow storage keys. That is just give management a copy to put in the fire proof safe. Or secret split or whatever.
I was actually thinking something along the lines of creating a file - encrypting it to your whole workgroup, and leaving it on a server. Now you have the advantage of not having any security problems even if the server is compromised [without workstation compromise, of course], and all the important people can access it. Of course, the last person to modify it resigns it, and it gets dropped into your RCS system. you get the added advantage of being able to rotate your keys here as well, so even if one key is compromised, and the server is compromised, you don't lose the whole system. Identical argument as for communications keys.
You could use multiple crypto recipient if you wanted to -- it's basically just another way of acheiving the same thing.
There is one (quite practical) reason, however, to use symmetric storage keys. Speed. If you're encrypting lots of files (perhaps using an encrypted parition driver such as Peter Gutmann's SFS), you won't have time to encrypt to public keys, never mind multiple public keys.
That's a different problem. For that you're [in this ultra-theoretical world] probably going to want something along the lines of this: Symmetric encryption for speed on the partition, and that key stored with several recipients in the same place as the Secure Partition Driver (SPD). (This falls in the, "If you're going to build a system, make sure you think of everythign you want and make sure it fits in the framework somewhere" method)
If the company keeps it's employee's storage keys in escrow, the fact that you're using a symmetric key works fine.
I'm not sure you need to escrow anything, as long as there is a way to share things among certain groups of people. Jon's ideas of non-hierarchical recovery systems seem a lot more secure anyway, especially with the rest of this thread. Oh - for the situation with Andy Grove (Intel CEO) describe earlier on this thread - let me give this suggestion: AG's key w/extra encryptions to CFO (or Pres. of Board, or someone else with significant influence and a close working relationship. Backup for problems with intransit e-mail.) Similar setups for everyone else in the company. Probably the top-level executives all have AG as the backup. This elminates snooping entirely in the company, on the top level execs. This partially hierarchical method wouldn't be horrible, and limits snooping to the level above you, or to peers, depending on setup.
Give an example of the difference between what he's doing and what you would propose. Otherwise you're just rejecting this system blindly.
I'm sure I've given these reasons earlier in the thread, but I'll summarise them again:
Yeah, you covered them fairly well, and cleared up the issues where I honestly thought it was a fear-mongering problem. I still don't completely agree with you, but we've clarified the problem areas. Thanks. (Too many wars get *way* too religous on the net. Let's try and avoid that here, ok?) -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBNECnJDc3ytqHnNyNAQGzAAP/bnYQQKdBnTY5HKc2fNlMYefYwZhdNXZo aYNDhmybGM8756SIp0uuKaaf1t2f22is1/XdxaN2aHO+5qyHSc/EwgV4tWeQ1SXt zBhMBM4phbTFSHl8FJUdRI9qcMxfoIfdoyJ5/CuYo83gJBwsrov6NZQylAlRR66K VUAohcY/BxM= =t0mO -----END PGP SIGNATURE----- ----------------------------------------------------------------------- Ryan Anderson - <Pug Majere> "Who knows, even the horse might sing" Wayne State University - CULMA "May you live in interesting times.." randerso@ece.eng.wayne.edu PGP Fingerprint - 7E 8E C6 54 96 AC D9 57 E4 F8 AE 9C 10 7E 78 C9 -----------------------------------------------------------------------
Ryan Anderson <randerso@ece.eng.wayne.edu> writes:
At 11:31 PM 10/11/97 +0100, Adam Back wrote:
to exchange mail with anyone without using GAK. Sure you have a "choice", you can send email to people that will bounce 100% of the time, whoever you send to due to lack of GAK compliance field. (Except for perhaps a few die hard cypherpunks).
My reading of Jon's post was that the SMTP policy enforcer only worked for outgoing messages. Perhaps that's wrong, but that needs to be double- checked. See below as well...
I'm fairly sure this is not the case. The reason I think that this is not the case is because Jon described two flags which go in the GAK compliancy sub-packet: Flag1: this flag is an advisory note to the person who obtains a public key which has the GAK compliancy self signature sub-packet; it tells the person about to use the key that the company the person who owns this public key works for would like it if you would "please" encrypt to the contained corporate snoopware master key. Flag2: this flag is the same as the flag1 above plus it is a big brotherish/little brotherish warning that if you _don't_ encrypt to the GAK compliancy key also, that the recipient will not receive the message. I understood the reason that the recipient will not receive the message when you don't honour keys with flag2 to be that the SMTP policy enforcer would either bounce the message, or eat it, or send it to the company snoopware czar to who can take due note in his employee dossier collection that this employee is receiving email from suspicious cypherpunk persons who don't believe in snoopware. The above functionality is the reason I'm arguing that PGP's method of implementing corporate snoopware is GAK compliant: clearly the whole system is ready tailored for GAK. The only thing left to do is plug in the governemnts key in the GAK compliancy field, and for the government to mandate that companies, and deputised ISPs use the software and the GAK master key. If/when this GAK compliancy gets used as the architecture for real live mandatory GAK, the SMTP policy enforcer may be set up to narc out the suspicious person who doesn't believe in GAK to the Feds/NSA, and they will then come and lock you up if they can trace your SMTP From field to you. This will make a mockery out remailers, because the remailer chain will also be forced to have the GAK master key in it as enforced by deputised ISPs running PGP's SMTP policy enforcers with GAK keys installed as the GAK master key.
It's not even needed if you don't have that key on your ring. (From what Jon said)
I'm not sure what you mean here.
The snooping key. If it doesn't exist on *my* keyring. (Say I have your key, but not the key designate as your snooping key...) [BTW: Forgive the English, I'm tired and speaking in choppy sentences]
Oh, I see what you mean. The reason I didn't understand is that this is not how I thought it works. I think the key is provided right there in the GAK compliancy field in an inseparable way. (I could be wrong on this, but this is the way I read Jon's message). Even if have misunderstood the way that this key is bundled, it doesn't really alter the fact that by "choosing" not to encrypt to messages with the flag2 flag you will know that this is a waste of time, because your message will not get past the SMTP policy enforcer. So purposely stripping the key from your key ring, or separating the key pair when someone sends you them together would just be another way of exercising the choice PGP is claiming you have in "choosing" to have your message bounced back at you. A fairly meaningless "choice". I would be interested to have this point about the way GAK compliancy key is bound/bundled with the GAK compliancy sub-packet clarified by a PGPer, or someone with more understanding of the draft docs, if this much information is available yet.
If I have your key, but not the other key that I'm also supposed to encrypt to, PGP (whichever versions, I'm not entirely sure how the feature set breaks down, but I believe this applies to all versions of 5.x) will not even mention that there was another key it would've have offered to encrypt to.
I don't think this is so because that would invalidate the semantics of the flag1 and flag2 flags, which are what instructs PGP to warn you of this requirement for this key. The flag is an attribute of the key itself, though I do suppose you might be able to strip off the attribute in much the same way as you can remove signatures from keys with pgp -krs.
Using separate storage keys allows you to:
- escrow storage keys within your company without including GAKware compliancy
- discard communications keys often (by giving them short life-spans) which greatly enhances your security
Greatly complicating the "web of trust" method, but..
I don't think it complicates web of trust. The only certification you need of communications keys is for you to sign them with your signature key. Your signature key semantics, and the web of trust is unchanged.
You can only chain signatures so far before you run into problems, and getting people to continuosly recertify could be a major pain,
It will be automatic .. you won't notice because all the OpenPGP compliant application which supports this proposed (strongly encouraged MAY, please!) feature will do when it creates a new communications key is to sign the communications key with your signature key. It won't involve third parties re-issuing certificates. It is the same way that certification and WoT interacts with potentially shorter life-span dual use encryption keys at the moment. The WoT certificates go on your longer life signature key, and it is you who signs your encryption key. Same argument, though now applied to encryption keys marked as "communications only".
There might be some security advantages to using symmetric keys even. (Public key sizes are a faster sliding and more uncertain target than symmetric key sizes.
Well, at least with RSA keys, I believe the memory requirements to handle current factoring algorithms are quite untenable for 2048 bit keys. I think 768 is out of the range of current systems.
512 bit I think is reckoned to be feasible for an academic crack of similar scale to the recent RSA challenge DES break. The memory for the final matrix crunching phase might be the only arguable point. However, this doesn't really give me 20 years worth of assurance because, well Rivest and friends encrypted the message "squeamish ossifrage" back in 1977 or thereabouts, firm in the belief that it would not be broken for 1000s of years. Factoring advances have meant that that ~380 bit keys (squeamish ossifrage was RSA129 digits decimal) is now relatively easy. Paul Leyland and friends broke a 384 bit blacknet key as a private attack without massive internet collaboration. I'm not sure anyones promising, or has any mathematical proof that new factoring algorithms won't provide similar factoring speedups. How many years are 1024 bit RSA keys good for? All you can use as estimators is the current factoring algorithms. I'm not sure how certain these estimates are for long term purposes. In contrast if there is nothin wrong with 3DES nor IDEA, the key space protects you, modulo Moore's law which is easier to predict. (Also modulo quantum computing break-throughs, in both cases, erk!)
I think this came up on the RC5 (Bovine) mailing list, and the figures for the required server was something absolutely ridiculous. To distribute the job using the more efficient algorithm required machines with 128 meg of ram, but the slower one was a bit more doable.
Yes. But memory on workstations is increasing in leaps and bounds. It is very common now for personal PCs and even laptops to have 32Meg. A few years ago we were living below the 640k barrier. Leave it a few years, and people will have the required memory levels. A few more years on from that people will be grizzling about living below the 4Gb barrier (restriction from using 32 bit addresses). Anyway, one of the factoring gurus may come up with another novel implementation or algorithm tweak to tune down memory requirements. Or a newly discovered faster factoring alorgithm may have huge memory advantages over current alogirthms.
In short, I don't think 2048 RSA keys are reasonable target in the forseeable future. [Remember, Moore's law is only applicable for another 12 years or so. Then quantum mechanics starts to be a serious problems, and electrons start switching channels in the chips.]
The future is uncertain. But it is marginally less uncertain for well tried and tested symmetric keys ciphers.
But this is a bit of a wandering topic now. Let me continue...
You can sign and encrypt with symmetric keys also. "pgp -cs." Quite a useful combination.
Hmm.. I must've missed that.
Don't think it says it anywhere, but you can combine flags in lots of logical ways which aren't documented as such, and most of which work as you might reasonaly extrapoloate them to. There are single letter flags for most letters of the alphabet, the full number of combinations must be quite large. Quite a few of them mean *something*. Some of them are even phonetically pleasing: -feast etc :-)
Well, I wasn't really encrypting anything I really cared about. It was backups of autoexec.bats and config.syss, I just wanted another copy that I *knew* when it was made, it wouldn't get overwritten, and it wouldn't get modified without me knowing. And I needed something to use PGP for, so...
Signature only might've been enough for backups of stuff in plaintext on the disk like autoexecs.
In all honesty, the public key baggage is 512 bytes ( I think, possibly bits. I've forgotten now ) Quite insignificant if you're dealing with CAD drawings.
Sure. But you were also talking about autoexecs and other small files where it could get significant. The significant lose howver is the performance -- say you recursively encrypt all the files in a directory, each to 2 or 3 multiple crypto recipients. It'll crawl.
It's probably simpler to just escrow storage keys. That is just give management a copy to put in the fire proof safe. Or secret split or whatever.
I was actually thinking something along the lines of creating a file - encrypting it to your whole workgroup, and leaving it on a server. Now you have the advantage of not having any security problems even if the server is compromised [without workstation compromise, of course], and all the important people can access it. Of course, the last person to modify it resigns it, and it gets dropped into your RCS system.
I see. Sounds reasonable. You should be able to achieve that with the current dual use PGP keys, or with the new "storage only" keys via crypto recipients. If your document is on the Internet, on the web perhaps, you'd need to be aware of the reduced security in using long term storage keys as opposed to short term communications keys, but other than that I can't see a problem. The point is that where you have a directional communication, you should treat those keys as sensitive. Where it is not a directional communication, you can't, so you lose that extra security; for applications where this is acceptable, I wouldn't argue for restricting your ability to do it.
you get the added advantage of being able to rotate your keys here as well, so even if one key is compromised, and the server is compromised, you don't lose the whole system. Identical argument as for communications keys.
I think I understand what you're saying for shared storage keys. But I don't think it's an identical argument at all for communications keys. If you define communications keys as short lived highly sensitive keys, as perhaps in SSL, or SSH (both of which use some forms of forward secrecy), you can't retain the ability to recover the message after the fact for security reasons. However I posit that people don't really want access to the plaintext stored inside encrypted communications for their own purposes for the simple reason that they don't have a sendmail log including all the message bodies. Together with the security advantages of not being able to decrypt communications traffic yourself after the fact, this argues that people who do want full email archives for company legal or snooping purposes, or just folder for their own use (I know I keep lots of email in folders) can either store in the clear, or store encrypted with a storage key, or store with an escrowed storage key, or store encrypted to multiple storage keys as crypto-recipients as you suggest.
There is one (quite practical) reason, however, to use symmetric storage keys. Speed. If you're encrypting lots of files (perhaps using an encrypted parition driver such as Peter Gutmann's SFS), you won't have time to encrypt to public keys, never mind multiple public keys.
That's a different problem. For that you're [in this ultra-theoretical world]
I don't think it's that theoretical. Don't PGP have such an encrypted disk driver for the MAC? I think this is the way forward for simpler storage encryption: encrypt the lot. Saves arguments about forgetting to encrypt stuff, or forgetting you did decrypt and leaving plaintext copies around in /tmp or whever as well.
probably going to want something along the lines of this: Symmetric encryption for speed on the partition, and that key stored with several recipients in the same place as the Secure Partition Driver (SPD).
Your suggestion is one reasonable way of acheiving this. You can also acheive the same flexibility with an extra indirection with symmetric storage keys (optionally held in escrow). In fact I think this is what later versions of Peter Gutmann's SFS do. The reason he uses for this is that it allows you to change your passphrase without re-encrypting the whole disk, because the _actual_ disk encryption key is encrypted itself with the hash of your passphrase, rather than using the hash of the passphrase directly as the key.
(This falls in the, "If you're going to build a system, make sure you think of everythign you want and make sure it fits in the framework somewhere" method)
Well I agree, I think it's reasonable for us to consider the major uses, plaintext recovery demands, and security aspects of the different types of uses for keys: transient communication keys, storage keys, and signature keys.
If the company keeps it's employee's storage keys in escrow, the fact that you're using a symmetric key works fine.
I'm not sure you need to escrow anything, as long as there is a way to share things among certain groups of people. Jon's ideas of non-hierarchical recovery systems seem a lot more secure anyway, especially with the rest of this thread.
It doesn't really matter one way or the other. You can build non-hierarchical recovery systems with either method. (You can escrow storage keys in your department, just as easily as add second crypto recipient within your department. I think the security is basically the same for escrow or multiple recipient when we're talking about storage. The same security equivalence argument applies if you accept the premise that you need access to transient communications. I don't accept this premise. This premise is a fallacy promulgated by the likes of Freeh. If you don't escrow communications keys at all you gain extra security for the same reason that it is less secure actually to escrow storage keys, or use multiple recipient as another way to achieve storage key escrow than to not use storage key escrow. However with storage you live with this because a) data availibility is important, and b) the risk isn't as great with storage because your attacker has to breach physical security to obtain the data from your disks and tapes.
Oh - for the situation with Andy Grove (Intel CEO) describe earlier on this thread - let me give this suggestion:
AG's key w/extra encryptions to CFO (or Pres. of Board, or someone else with significant influence and a close working relationship. Backup for problems with intransit e-mail.)
Similar setups for everyone else in the company. Probably the top-level executives all have AG as the backup. This elminates snooping entirely in the company, on the top level execs. This partially hierarchical method wouldn't be horrible, and limits snooping to the level above you, or to peers, depending on setup.
The suggestions about snooping heirarchy -- who can read who's mail within the company -- are independent of which architecture you choose to use to allow access to the mail (escrow storage keys or use multiple crypto recipient for storage keys). (This can all be enforced with similar levels of resistance to bypass by building the archive and snooping features into the mail client to do this after decryption). Where you start to get argument from me is when you start unduly exposing what should be transient communications keys to construct this corporate snooping pecking order.
I'm sure I've given these reasons earlier in the thread, but I'll summarise them again:
Yeah, you covered them fairly well, and cleared up the issues where I honestly thought it was a fear-mongering problem. I still don't completely agree with you, but we've clarified the problem areas. Thanks.
That's what it's all about -- meaningful discourse so that we can collectively improve each others understanding of the problems at hand, pointing out flaws in each others arguments until we reach agreement, eliminating misunderstanding. With that a clarified picture of the security issues and best architecture, we can then go on to design suitable security protocols which best reflect this.
(Too many wars get *way* too religous on the net. Let's try and avoid that here, ok?)
Hey, as long as we steer clear of PGP arguments about mandatory GAK compliancy, this is all friendly discourse :-) On religious arguments: I must admit to strong negative feelings about PGP Inc or the OpenPGP standard using weaker security methods to enable GAK compliancy. My reason for expressing these opinions is the hope that we can talk PGP out of this big brotherish SMTP policy enforcer, and associated GAK compliant fields, and to give my input to try to steer the OpenPGP process away from incorporating said GAK compliancy field into the standard. Also as I hope I have explained relatively clearly in my other post titled: Subject: negative security aspects of GAK compliance that GAK compliancy is independently from political arguments a security design flaw. And so I think that we should be able to reject it on technical grounds alone as a design with weaker security. 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`
Jon Callas <jon@pgp.com> writes:
A number of people have asserted that the Corporate Message Recovery feature is key escrow. From where I sit, the difference is easy to see. My definition of "key escrow" is that another person or organization keeps a copy of the user's secret key.
You are adopting a narrow technical meaning of key escrow. Key escrow also has another meaning in common parlance: third party access to communications. Now I know this common parlance isn't technically accurate, but "key escrow" itself is a piece of newspeak, a clever term coined by secret service / government spin doctors. It has entered the language like it or not (I don't like it). This common parlance meaning is probably more widely understood and used than the technical meaning you are using. With that in mind, you may start to see why people, such as Schneier, and others over the last few days have been telling you "you're picking nits". Point is pgp 5.5 allows other people to have access to your communications. Your SMTP policy enforcer even attempts to enforce this. You also described a feature whereby an administrator could remotely configure and restrict functionality in pgp 5.5 mail client (I am unclear as to whether this allows the admin to enforce snoop access or not). Your own term CMR (Corporate Message Recovery) isn't that accurate a description itself, it's a bit of a euphamism at best. What you're recovering is transient communications which don't need recovering anyway. What PGP is really up to is enforcing capability for Corporate Message Snooping. [line breaks were _all over_ the shop, I've reformatted]
Here's an example, based on actual customers who use key escrow to manage their data:
This corporation uses PGP for a number of things. Email, engineering plans, CAD drawings, and so on. They've done so at least since the days when we were Viacrypt, and I believe they even used PGP 2.x.
First point, which I'm getting bored of repeating: keys have different uses. Storage keys, transient communications keys, signature keys. You're using one key for all 2 functions; that is the root of your problems and dilemmas. You're using what should be a storage key to receive transient communications, then you're proceeding to wonder why this causes you to have the undesirable situation of having a GAK compliant system (or more properly trying and failing to argue that you don't have one).
When an employee arrives at this company, they create a key pair for the new employee, hand it to them on a floppy, keeping a duplicate floppy with the keypair on it, which they toss into a safe. Literally. This is key escrow. They do this because they can't afford to lose their files and messages. Their policies require them to keep the secret keys, as if they were the same as keys to offices or file cabinets.
You know, what they're doing: it's not so bad for data encrypted on their disks. They can acheive the departmental level escrow to distribute risk just the same with this form of escrow. You don't need to escrow transient communications keys at all anyway. Your pgp 5.5 isn't going to help recover the actual data of value, all those stored CAD files... You know why? Because they're on the disk, not in transit in the email system. So you haven't solved the claimed problem. If you want to do something about the claimed problem work out some secret splitting solutions to better distribute trust for escrowed storage keys. (Now this is a real use for escrow: the company is safe guarding it's own encrypted data on disks and tapes for it's own benefit).
- From our standpoint, the issue gets even touchier. They don't like what they're doing, and they want us to give them a better way to manage their data. Does anyone really believe that only moral response is to flinch and turn away?
Nope, your responsibility should be to solve their problems. (Which as I show above you have not done.) Actually your responsibility to live up to the reputation PRZ transfered to PGP Inc dictates that you should also do what you can do not build systems which help GAKkers. Instead your responsibility appears increasingly to produce systems which smooth the way for coming mandatory GAK by implementing systems which are GAK ready. Or if you deny that one, at least you are weakening your communications security for practically no gain.
I'd like to be in a situation where I didn't have to deal with this. Wanna trade positions?
Yeah, OK, you don't seem to be managing very well :-) (Sorry, you asked for it. I don't actually mean to be rude, I would just like to get the points across, and to influence PGP to recover gracefully from this tactical and reputational mistake.)
It isn't so with a CMRK. The worst possible way to use the feature is to have a single, company-wide CMRK. If that gets lost, the thriller you can write isn't nearly as interesting. Yup, you can steal any of the plans, read all the mail, and so on. That's bad. It's deplorable, actually. But it isn't a difference that makes no difference. At least there isn't a gang of keys out there that can sign anything with anyone's ID.
This is why I was asking above about separate signing keys. They surely don't need to stick the signature keys in the safe!!! In fact it is counter-productive even for hard-nosed corporate lawyers, and $$$ driven scruple-short company execs: if they can't prove an employee penned something they can't use this to prove a case against him. If they've got a copy of the signature key, they can forge signatures which makes signatures useless in litigation involving company and employee.
This is not the only way to use Corporate Message Recovery, it's just the worst way. Remember, it's just a notation in the self-signature that states, "When you encrypt to me, encrypt to X." That's any X. You can have a different CMRK for every department, every workgroup, or even every user.
It's all screwey because you've got key functionality which belongs in different keys mixed up. You should have 3 types of key: 1. signature keys 2. transient encryption keys 3. storage keys The signature keys you never escrow. You certify. If something goes wrong you re-issue, release revocation cert, and re-certificate. The transient encryption keys are for communications, you delete them immediately after use. Yes I'm talking forward secrecy here. If you don't like forward secrecy, well at least don't escrow the encryption keys. Storage keys you make damn sure you can recover. You escrow these for real. Company safe sounds about right. Secret splitting could be nice also.
The significant improvement that PGP's web of trust has over a traditional hierarchical system is that you can set up a top-down system for validity, but you don't have to (and in our opinion, shouldn't). Analogously, the significant improvement that Corporate Message Recovery has over key escrow is that you can tailor a recovery system to your needs (including and especially deciding it's not for you).
There is no advantage; the systems are approximately equivalent in flexibility of architecture. You can acheive the exact same architecture with key escrow; just escrow the keys with your backup czar. You shouldn't be recovering transient messages, you should be recovering stored data. 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----- In <199710110112.CAA06510@server.test.net>, on 10/10/97 at 08, Adam Back <aba@dcs.ex.ac.uk> said: Ok Adam here is a challenge for you: - -- Explain why Corporations do not have the right to access *their* documents in whatever form they may be in. - -- Failing that explain how PGP 5.5 furthers the cause of GAK and PGP 2.6.x does not when I can get my network to do the same thing in a weekend and a couple of scripts using PGP 2.6.x. - -- Failing that explain why there were no great outcries that PGP 2.6.x is GAKware??? Now if you agree that Corporations *do* have a right to access their documents but you disagree with the technical aspects of how PGP 5.5 achieves this then drop the fearmongering and spell out how you think this can be better achieved. - -- - --------------------------------------------------------------- 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 - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBND8CqI9Co1n+aLhhAQGoJwP+P5InFFnaH5svFrdnlREW08lOlYKrLjHH 95/X669e3RK+l9Oaj0svN8DxMV53GnRj+4spb8c7UpYLmUV0ZGvf+mORog6rwYaP 65Gl+wgNTdkJefENxAr6aofTU+zwYUgklUSPfl6+y5Hn8xlwftpuRxNjs4W2muGz VR1RYTQKQIE= =Z81q -----END PGP SIGNATURE-----
Williams title being: `Why Adam Back keeps politicizing technical issues' I would like to comment that the reason politics are arising in discussion of communications security issues is a natural consequence of the fact that it's a damn political topic. Ignore the politics and you may implement a mandatory GAK system, or at least a GAK compliant one. Actually I also argue that there are technical security reasons why the CMR approach offers weaker security. I've gone over these reasons already in this thread, so I won't repeat them. IETF I think has a stated policy (at least this is the case for the IPSEC standardisation discussions I have been intermittently following) to not allow politics to weaken it's protocols and algorithm choices. PGP Inc introducing GAK compliance at the cost of security is a clear case where this policy should be kicking in. William Geiger <whgiii@invweb.net> writes:
In <199710110112.CAA06510@server.test.net>, on 10/10/97 at 08, Adam Back <aba@dcs.ex.ac.uk> said:
Ok Adam here is a challenge for you:
-- Explain why Corporations do not have the right to access *their* documents in whatever form they may be in.
You will note that I didn't say this. In fact I spent half of last night detailing alternate less GAK friendly ways for PGP Inc to provide corporate message snooping, the very functionality which is the motivation for their CMR. Perhas you were not reading. What I did say, and it appears to be a meme which didn't stick with you as I'm sure I raised this in a previous post replying to you is: Key functionality should be separated: in the same way that you have separate signature and encryption keys, because of the differences between appropriate backup policies, security implications, and life-times, you should have separate email receipt encryption keys and storage keys. Transient email receipt keys should not be escrowed, but for security reasons perhaps should even be securely wiped after use. As an additional security bonus: storage keys can be symmetric (where they are for your own use) which avoids the more less certain and more quickly sliding target of public key lengths. I will guess that the reason this meme doesn't suit you is that it's not the way your OS/2 pgp mail client plugins work, and therefore not yet part of your mindset. So perhaps it's not the status quo for your and some other apps to use separate storage keys for archiving and receiving encrypted mail; but there are clear security advantages to doing it this way.
-- Failing that explain how PGP 5.5 furthers the cause of GAK and PGP 2.6.x does not when I can get my network to do the same thing in a weekend and a couple of scripts using PGP 2.6.x.
There is are some clear differences: 1. You can visually see multiple crypto recipients in most PGP enabled MUAs, as they usually correspond to email CC fields. 2. PGP Inc is attempting to weakly enforce this special purpose message snooping recipient embedded into the key certificate. 3. PGP Inc even has (less clear on details here) I think from Jon Callas first post: pgp 5.5 client which enforces inclusion on sent mail as controlled by a remote company message snooping czar & enforced inclusion on received mail by the SMTP policy enforcer. 4. There is a difference between what you or I may knock up in scripts, and what PGP Inc attempts to persuade the IETF include as conformancy requirements, and what PGP does implement ahead of the standardisation process. 5. The IETF process should be accepting proposed designs and deciding on the best ones, which PGP Inc, and the other suppliers would then go and implement. As it is now, as William Allen Simpson just pointed out, PGP Inc is cruising ahead implementing, and deploying things without bothering with the OpenPGP process. Your point about using normal multiple recipient to provide snooping is a good one. It would be a much less GAK friendly solution for PGP Inc to encrypt to a second recipient without any message snooping flags encoded into the PGP standard. That way email clients won't reply to this second recipient, and users won't have an automated snooping feature embeded in their PGP for personal privacy, or competitor re-write of the same compliant OpenPGP app, for someone else's benefit (recipient company, or government). To snoop received email, it provides similar amounts of snooping enforcement if the recipient's PGP 5.5 for business client when the user decrypts re-encrypts to a storage key that the company does have escrowed, or where there is a second crypto recipient in the storage. (Talking mail folders here.)
-- Failing that explain why there were no great outcries that PGP 2.6.x is GAKware???
See above. The objectionable new feature in PGP5.5 (and apparently pgp5.0 too without our realisation to this point) is enforcement in senders clients to support message snooping, in a form which can easily be used to interoperate with GAK, and thereby prepares everyones OpenPGP compliant email client to enforce GAK against them. At the very most the maximum acknowledgement that it seems reasonable to me for OpenPGP to have of the GAK compliancy feature is to flag this key and allow the user to send to this recipient at their option. In addition I am arguing that PGP Inc are doing the Internet community a major disservice by choosing to implement message snooping in this way. Much better, less controversial, and more secure to do the snooping in the pgp5.5 client after decryption. That doesn't need to involve changes to the message spec. PGP Inc's SMTP policy enforcer could then be changed in functionality to stripping off the company snooping crypto recipient field before it leaves the LAN for security reasons.
Now if you agree that Corporations *do* have a right to access their documents but you disagree with the technical aspects of how PGP 5.5 achieves this then drop the fearmongering and spell out how you think this can be better achieved.
I already did this half a dozen times. I'm not fear mongering, I'm attempting to point out the dangers of including GAK compliancy. And to point out the opportunity to make PGP non-GAK compliant, and thereby frustrate mandatory GAK proponents. PGP is trying to discard this opportunity, when there are clear alternate methods which can be argued are more secure, better meet PGP's Jon Callas's stated user requirements, don't support GAK, and don't require modifications to the standard. 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:41 AM -0700 10/11/97, Adam Back wrote:
5. The IETF process should be accepting proposed designs and deciding on the best ones, which PGP Inc, and the other suppliers would then go and implement. As it is now, as William Allen Simpson just pointed out, PGP Inc is cruising ahead implementing, and deploying things without bothering with the OpenPGP process.
Just a quick reality check here. Frequently implementations have proceeded IETF standards. That is one of the strengths of the IETF process (as compared with e.g the CCITT.) ------------------------------------------------------------------------- Bill Frantz | Internal surveillance | Periwinkle -- Consulting (408)356-8506 | helped make the USSR the | 16345 Englewood Ave. frantz@netcom.com | nation it is today. | Los Gatos, CA 95032, USA
Bill Frantz <frantz@netcom.com> writes:
At 2:41 AM -0700 10/11/97, Adam Back wrote:
5. The IETF process should be accepting proposed designs and deciding on the best ones, which PGP Inc, and the other suppliers would then go and implement. As it is now, as William Allen Simpson just pointed out, PGP Inc is cruising ahead implementing, and deploying things without bothering with the OpenPGP process.
Just a quick reality check here. Frequently implementations have proceeded IETF standards. That is one of the strengths of the IETF process (as compared with e.g the CCITT.)
I must admit some ignorance of the IETF processes due to my only understandings being gained from intermittent following of the IPSEC standardisation process, and in that respect I thank you for the data point... However, I would defend that my understanding is, and my point was more that proposals with trial implementations should be used as discussion points, and as competing draft proposals rather than being used as arguments for it being necessary to build compatibility with just because someone has rushed off and sold copies of them, prior to ratification of those proposals by the standardisation process. And that independently of the technical merits of those proposals, or arguably even in the face of evidence that there are more secure alternatives to these proposals. The IETF standardisation process is supposed to make decisions based on technical merit. Not based on marketing clout. Nor even based on reputation capital, something which PGP surely has in abundance, as transferred to it by Phil Zimmermann with his virtual net.god status. I also take exception to PGP's Will Price's attempt at silencing negative discussion of the security and political aspects of PGP's GAKware, in his rhetoric on this being an inappropriate forum for discussion of political aspects of CMR. If Will Price thinks that we should just lie down and accept PGP fielding inferior security GAKware systems, and accept PGP trying to impose them on the standard, he can think again. Crypto politics can't help but play some part in discussion of crypto standards. As Tim May pointed out in an earlier post, we gave the same roasting to companies participating in the Key Recovery Alliance Program, and to companies like TIS, and IBM for various GAK sell out deals. In fact, Netscape got worse roastings for far lesser crimes than PGP's crimes in attempting to architect GAKware into the OpenPGP standard, or if that fails, in PGP's death wish in attempting to commit reputational suicide by implementing and widely deploying GAKware. My concern specifically is that some of the less desirable aspects of the way that PGP have implemented CMR should not be adopted into the standard for interoperability reasons alone. I am worrying that PGP Inc will shortly be using this line of reasoning, for backwards compatibility with pgp5.5 functionality for similar reasons as one might reasonably argue for backwards compatibility with pgp2.x. I noticed that Ian Grigg (Systemics) also expressed this point about standards process manipulation well in his article. Systemics has a much better track record for open development, and openness of design decisions than PGP Inc since it's incorporation, or before that than the pgp3.0 development team of two in beetling themselves off in a room at Sun or wherever and taking ages to develop software. (No offense intended to said developers technical ability, which I respect immensely, the error was organisational.) Systemics is also outside of the US and for that reason better placed to compete internationally. PGP Inc is losing reputation capital to Systemics and other such small companies in eroding it's support from netizens by fielding GAKware systems. (I have no affiliation with Systemics). Adam
On Oct 13, 12:40pm, Adam Back wrote:
Subject: Re: IETF policy on refusing to allow politics to weaken protocols
Bill Frantz <frantz@netcom.com> writes:
At 2:41 AM -0700 10/11/97, Adam Back wrote:
5. The IETF process should be accepting proposed designs and deciding on the best ones, which PGP Inc, and the other suppliers would then go and implement. As it is now, as William Allen Simpson just pointed out, PGP Inc is cruising ahead implementing, and deploying things without bothering with the OpenPGP process.
Just a quick reality check here. Frequently implementations have proceeded IETF standards. That is one of the strengths of the IETF process (as compared with e.g the CCITT.)
The reality is that standards generally drag long behind the need for new technology. In any standards org worth thier weight in salt, the group will look at existing implementations (not trial implementations but ones that have been in use for some time). This is called 'Prior Art'. Without prior art, it is not easy to determine which features or schemes work and which do not. The problem we are running into here is that PGP Inc. is marketting about the only prior art available for this technology. In addition, business needs will not stand still waiting for a standard to come out in 1-2 years. This creates a somewhat dangerous situation as Adam has pointed out (Note: I am NOT PGP-Inc.-bashing. This is merely an outcome of what happens when a vendor tries to take their technology and 'open' it up). I would be concerned if this relatively new addition were being added to the internet-drafts currently being produced by the group. I know they have tried to wrestle with all of the issues. I just think we need some more 'experiential' evidence that it is the correct solution. In general, standards only describe the 'bare-minimum' that an implementation must do to be 'compliant'. There is nothing wrong with leaving certain bells-and-whistles out of the first pass at a standard. Vendors are always free to add proprietary features to thier product. That is where the market competition comes in. PGP Inc. implements thier CMR feature on top of the OpenPGP standard. Another company attacks the problem a different way and adds a different 'extension'. In about 5 years, a new standards group updates the 'OpenPGP' standard, argues over the different schemes and adopts the one with the best technical merit.
I must admit some ignorance of the IETF processes due to my only understandings being gained from intermittent following of the IPSEC standardisation process, and in that respect I thank you for the data point...
However, I would defend that my understanding is, and my point was more that proposals with trial implementations should be used as discussion points, and as competing draft proposals rather than being used as arguments for it being necessary to build compatibility with just because someone has rushed off and sold copies of them, prior to ratification of those proposals by the standardisation process. And that independently of the technical merits of those proposals, or arguably even in the face of evidence that there are more secure alternatives to these proposals.
The IETF standardisation process is supposed to make decisions based on technical merit. Not based on marketing clout. Nor even based on reputation capital, something which PGP surely has in abundance, as transferred to it by Phil Zimmermann with his virtual net.god status.
To Adam and others, I would say, work like mad to develop pgp-like implementations (based on available documents of 2.6 or 5.0 formats) and add in alternative mechanisms to do the same function (as per Adam's discussion of the 3-key system : signature, transit-encryption, and storage). To others in this group, I would say keep it simple...especially on a first pass at a standard. I have noticed an interesting phenomena in a number of IETF groups. One group develops a standard that is huge and nearly unimplementable. Another group comes along and says "We can do it simpler than that". They start designing and writing documents, run into the same issues the first group did and eventually start solving them the same way leading to another large unimplementable standard. Witness: X509 -> PKIX -> SPKI -> OpenPGP. OpenPGP was supposed to be different because it had a large established user base. Then, all of a sudden, everyone is arguing over the same issues as the first three groups...global naming problems, certificate flexibility, key recovery, policy enforcement...
...
Adam -- End of excerpt from Adam Back
-- Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 *****
participants (6)
-
Adam Back -
Bill Frantz -
Jon Callas -
Ryan Anderson -
Tony Mione -
William H. Geiger III