Kent Crispin <kent(_at_)bywater(_dot_)songbird(_dot_)com> writes:
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.
Fact is pgp5.x _does_ support one form of forward secrecy already.
Furthermore, forward secrecy in the existing email infrastructure is
a known difficult problem, is it not?
No, if you're willing to have delayed forward secrecy, perhaps once
every 6 months, it's pretty easy. pgp5.0 provides everything you need
to interoperate with such key usage.
So, taking PGP to task for not providing forward secrecy is just hot
air.
They have provided a form of forward secrecy: separate expiry times on
encryption keys. All that needs to be done about that approach to
forward secrecy is to explain it in the security recommendations.
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 why pgp5.x has key expiry facilities; this part of the
argument is simple enough -- explain what key expiry can be used for:
- to reduce value of one key to an attacker
- or to delete private half some time after expiry
This is just as true for Key Escrow schemes as it is for Multiple
Encryption schemes. Despite the FUD, the risks are very
similar. (*)
It's potentially more dangerous for message recovery schemes because
the company is likley to use one long term key to provide backdoors
into many messages. It is also more dangerous because there are now
TWO long term keys instead of one.
However much you want to downplay the danger, the fact is it is simply
an unnecessary security risk; there are much simpler, and safer
message recovery techniques, PGP Inc employees tell us their customers
were already using such techniques on an ad-hoc basis (floppies in
safe). Implementors of commercial use OpenPGP software can improve
upon their customers existing practice of escrowing floppies (and
passphrases one presumes) by providing support to avoid escrowing of
signature keys.
Simple, requires no CMR definitions in the standard, meets all message
recovery user requirements, and is more secure too boot.
(*) 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.
Implementors can build keysafes without CMR. It is more secure to do
so than to use CMR.
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),
There are two kinds of key "expiry"; key reaches expiry date; and user
forgets passphrase.
Re-encrypting everything to a new key is PGP Inc's current practice,
which I agree isn't very ergonomic -- in fact I don't think they
provide any software to automate this problematic task.
throw away the data (not likely),
or keep a database of expired keys (the only realistic solution).]
You seem to be talking about storage. For storage you wouldn't expire
the keys until you did want to throw away the data. Several people
have expressed that they actually want to _destroy_ data after certain
periods for some applications. (Where the data expiry period is
determined by their legal departments, based on record storage
requirements, and limitation of risks of lawsuits involving discovery
processes to retain data which would be better burnt from companies
point of view.)
For messages it is good security practice to throw away the key after
usage. You seem to be jumping to conclusions about short expiry
times. In an earlier example I gave a key expiry of 6 months. Say
that you discard communications only keys a further 6 months after
expiry. I can't see you losing many emails in transit over that one.
All the support to cope with such usage is built right into pgp5.0 and
pgp5.5; automated fetching of new keys from key servers when the user
attempts to use an expired key, and checking of certification on new
keys.
Separate storage keys are obviously a good idea, the difference in
use, and different security risks demand this.
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.
If you're talking about storage it seems to me that you'd want to keep
the keys as long as you keep the data. There might be some value in
expiring and more securely storing keys for very old backups which you
aren't intending to use much. Perhaps you could write a few
paragraphs describing this kind of tradeoff for inclusion in the
security recommendations of the draft. One suspects it might be a bit
advanced at this stage; most people are have enough work getting
implementations out at all. It is a nice thought though, and probably
worth documenting in my view.
[...]
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."
Sure, but you could say: "implementations SHOULD generate new keys
periodically". Or implementations are recommended to in security
recommendations. Even a 6 month expiry and 12 month key desctruction
period has great value.
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.
With pgp5.x the infrastructure is here. Updating keys once per month,
or once every 6 months should present no problem. You would delay
deleting the key for some kludge factor after the key expiry to still
be able to decrypt emails in transit. Be generous, double the expiry
period before you delete the key, if you're suspicious of losing
messages.
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.
Yes, but not the way you mean it. PGP Inc has some investment in CMR,
therefore they will naturally want to protect that investment. The
rest of participants mostly seem to agree that there are better ways
to do message recovery, which can be acheived outside the packet
standard even, with current pgp5.x packet sets.
My only interest in CMR is to see it phased out; mentions in the draft
if any should be in terms of being a feature retained for backwards
compatibility only.
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(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`