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, but there is a good security
case arguing against use of CMR for either of it's argued purposes.
(Disaster recovery of stored messages, and corporate snooping of
messages in transit, or company reading of queued waiting for
decryption in employee's absence).
We can go over these again in detail if it would be useful for the
standardisation process.
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.)
Let's make this quite clear.
There are more secure ways to achieve the following:
- recovery of encrypted archived emails
- ability for companies to decrypt email in transit
I am quite happy to go over these again.
Certainly, there are security implications as far as message
recovery is concerned, but security considerations are
application-specific -- that is, most commercial applications don't
require anything approaching military-grade secrecy.
This is true. Should we add single DES (56 bit key space) because of
this? I didn't notice anybody argue for this (except for WengFatt
Fong <wffong(_at_)ca(_dot_)ibm(_dot_)com> -- if that wasn't a troll). Should
we have
DES because it is possible to export it if you are in the US and your
company agrees to plan for GAK on a 2 year time-schedule? Should we
then add in the facilities for that GAK? (Eeek, no need we've already
got that: CMR). This doesn't sound in line with IPSEC stuff I
followed where political weakening of security standards has
specifically been rejected.
And certainly, with care, CMR as implemented by PGP can be *very*
secure.
It is demonstrably less secure.
What is worse though is that long term communications keys are being
encouraged by PGP Inc. This is definately less secure. Much less
secure.
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.
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 what is said should
be reflected in the standard?
To put it a bit more baldly, the question is are you willing to
disrupt the process if you don't get things your way?
I don't see it as disruptive to make a security case against a
proposed feature. I see that as very constructive, similarly to the
constructiveness of discussions rejecting 56 bit key lengths which
might otherwise be argued for on political grounds.
And, given that some people will answer that in the affirmative, how
would you expect the WG chair to handle it?
I have some hope left that a sensible outcome can be acheived.
One outcome could be this. The CMR approach is defined for backwards
compatibility with the brand new pgp5.5 (how many copies of pgp5.5 for
business sold? Is it shipping in non-beta yet?) (I argue against
this outcome, btw).
A privacy respecting definition of CMR functionality could be defined.
ie. Arrange that the sender has two choices when sending to a CMR key,
reflecting two types of messages, "official company business"
messages, and "personal" messages.
1. official company business, fill in the correct key in the second recipient
2. personal messages, fill in garbage in the second recipient
Language in the security recommendations stating that new CMR usage is
discouraged (SHOULD NOT) and only supported for backwards
compatibility reasons. More secure alternatives given.
Personally I would hope that CMR could be simply removed altogether
however, and that pgp5.5 is modified to be inline with the standard on
this point.
PGP Inc could have coped with migrating to new methods outside of the
standard without introducing compatibility problems if they had used
an extension mechanism. For example if systems capable of responding
to ARR requests had been defined to use a version number, or extension
flag in a message header.
As they didn't depending on how important pgp5.5 for business
compatibility is we may have to live with something like the above.
I would encourage a formalised extension mechanism to avoid further
such problems.
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`