On Thu, Oct 30, 1997 at 10:45:48PM +0000, Adam Back wrote:
Kent Crispin <kent(_at_)bywater(_dot_)songbird(_dot_)com> writes:
On Thu, Oct 30, 1997 at 04:11:20PM +0100, Ulf M=F6ller wrote:
Several WG members and other recognized crypto experts consider any
form of message recovery dangerous, others do not agree with the way
it is implemented in PGP in particular.
However, these are primarily political considerations.
There are certainly political considerations.
There are also very good security considerations.
I'm sure we went through all this before,
Oh, indeed.
but there is a good security
case arguing against use of CMR for either of it's argued purposes.
There is a minor security case, IMO. Given that PGP2.6 uses long-term
communication keys the argument that 5.x should support forward
secrecy is specious. Furthermore, forward secrecy in the existing
email infrastructure is a known difficult problem, is it not? And
despit your aggressive early innuendo to the contrary, I don't see a
solution from you.
Instead, what I see from you are waving hands spelling out KEY ESCROW
in big letters. There is nothing very original in that.
So, taking PGP to task for not providing forward secrecy is just hot
air. Any scheme that doesn't provide forward secrecy is going to
leave gobs of ciphertext exposed under the same key for some time, by
definition. This is just as true for Key Escrow schemes as it is for
Multiple Encryption schemes. Despite the FUD, the risks are very
similar. (*)
As far as Corporate Data Recovery is concerned, you have blown a
stream of bubbly ideas -- yes, I have read http://..., no, I am not
impressed -- there isn't anything more than slightly elaborated KEY
ESCROW again.
To summarize. PGP didn't solve the forward secrecy problem; neither
do you. Key Escrow is a slightly better solution, IMO, but the
tradeoffs are complex.
(*) Your analysis avoids the problem of key management. In both
scenarios (Individual Key Escrow vs Dual Encryption (CMR)) the real
issue is the mechanism for protecting the keys. In the IKE case you
have a repository for the escrowed keys -- the "keysafe" model I
discussed some time ago. The "keysafe" is a database in a
cryptographic safe, and has a key of its own. [The Keysafe key is a
weakness.] CMR actually requires a keysafe as well -- good practice
would dictate that an organization segment their data across several
recovery keys, and that they expire fairly quickly. [When keys expire,
you have three choices -- reencrypt everything to a new key (stupid),
throw away the data (not likely), or keep a database of expired keys
(the only realistic solution).]
In both cases, you end up with a big pot of encrypted data encrypted
by different keys, and no single key can decrypt more than a certain
fraction of the total data. With IKE the granularity is finer,
probably, but it is adjustable in either case.
So, in sum, the advantage you claim for key escrow is real, but
relatively minor.
Note that there may be other models for managing large numbers of keys
besides a "keysafe" -- someone could make a lot of money by designing
and coding a good one -- but I believe the problems are generic.
[...]
When we start talking about key lengths, you get fairly clear
consensus -- much opposition is displayed to the notion of allowing
politics to weaken security. (Sure Kent, 40 bits, or 56 bits might
arguably enough for some applications, if one uses your argument.)
[...]
This doesn't sound in line with IPSEC stuff I
followed where political weakening of security standards has
specifically been rejected.
From the IETF perspective, there is a vast difference between a
protocol issue, like keylength, and an operational issue, like key
management. Operational issues are of a different character. You
can't say "The user MUST change his key every week", for example.
Realistically, you can't even say "Conforming implementations MUST
generate a new key automatically after 30 days."
And certainly, with care, CMR as implemented by PGP can be *very*
secure.
It is demonstrably less secure.
You say tomahto, I say tomayto.
What is worse though is that long term communications keys are being
encouraged by PGP Inc. This is definately less secure. Much less
secure.
As noted, the long term communication keys are a problem of
infrastructure, not PGP.
In real applications this may make more difference to security than
the difference between 56 bit DES and 128 bit IDEA -- the weakest link
in a public key crypto system is likely to be the long term decryption
keys. Protecting them more carefully (by destroying them after
expiry) arguably adds more extra real-life security than the extra 72
bits of keyspace when combined with bad key management practice as it
is now.
Having two long term keys exacerbates this problem. Having a CMR key
which is used to recover many employees messages is even worse.
This is all true. However, "worse" is a relative term.
So, if the IESG gives its WG chairs the power to decide whatever they
consider appropriate, fine, but please save ourselves the Newspeak of
calling that "rough consensus".
Perhaps, then, you would rather have no standard at all, than a
standard that refers to PGP's CMR implementation?
Most who have voiced their opinion on the topic have expressed
negative opinions of CMR. Perhaps this says something about the
technical and political demerits of CMR?
Perhaps it rather says something about who is vocal and who isn't.
Perhaps what is said should
be reflected in the standard?
To some extent, yes. My opinion is that a PGP "packet" standard would
be a big win, and that the CMR debate is really just breaking waves in
shallow water.
--
Kent Crispin "No reason to get excited",
kent(_at_)songbird(_dot_)com the thief he kindly spoke...
PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html