Re: Just say NO to key escrow or CMR/ARR revisited

["Richard Johnson" <rdump@xxxxxxxxx>]

At 15:49 -0700 on 11/05/1997, William H. Geiger III wrote:
> In <v03110702b086a28c9aa5@xxxxxxxxxxxxxxxxxxxx>, on 11/05/97
>    at 03:32 PM, "Richard Johnson" <rdump@xxxxxxxxx> said:
>
> >It is not fear-mongering to request that the tags not even be defined
> >because they unnecessarily weaken the security of the standard.
>
> How does having a request tag in the key weaken security?? The tag can be
> used or ignored as the implementors see fit. No one is saying that you
> MUST respect the request tag and no one is saying that you MUST generate
> keys that contain such flags.
>

If only it were just a request tag.  PGP Inc's SMTP policy enforcer turns
the "request" into more of a demand.  It says, in its most strict
incarnation, 'encrypt to a 3rd party key we specify, or else your message
will not be allowed to reach the intended recipients.'  (Given the tags in
the messages, if PGP didn't write such an enforcer, someone else would
have.)


> >Please, let's not place hooks that can easily be abused to require
> >encryption to 3rd party keys into the standard.  Enforcement of such
> >requirements by software such as PGP's SMTP agent are all too real
> >possibilities (er, that exists already, doesn't it).
>
> <sigh> the biggest "hook" for the type of abuse you are so fearfull of is
> the ability to encrypt to multiple keys. The CMR tag is quite trivial
> compaired to this. So are you willing to continue with your logic that
> such "hooks" are to be avoided and call for a complete re-write of PGP so
> this can be advoided??
>

The problem I'm worried about is _forced_ encryption to 3rd party keys by
senders who don't need or desire to encrypt to those keys, but acquiese
because their messages won't get through if they don't.

Here, we just differ by a matter of degree.  Taking your point about
encryption to multiple keys being a "hook" a (large) step further, the
ability to encrypt to even a single key is a "hook" that should probably be
avoided if we want to keep attackers from having any chance of decrypting
the message.

Humor aside, I think capabilities that can easily be abused (and are being
abused?) to _require_ encryption to 3rd party keys do not belong in the
open-pgp specification.

Such features offer a many orders of magnitude reduction of effort and
storage needs to a drift-net attacker who wants to decrypt a large number
of messages.  Instead of having to obtain, sort and use thousands of
individual keys, the attacker will only need to steal (or legislatively
require access to) a single high value, long term recovery key.

Also, in a worst-case attack scenario where the adversary is a national
government (not necessarily your government...), it will certainly be
politically easier for them to require access to recovery keys, as a wedge,
than it will be to require access to all individual keys.  Granted, either
could be achieved by a government, but the high value recovery keys will be
easier for them to both obtain and manage.

In other attack scenarios with fewer overtones of big brother (or big
French uncle), a high value, long term recovery key still reduces the work
that needs to be done by an attacker seeking to perform corporate espionage.

Message recovery, as implemented in PGP 5.5 with forceable encryption to
3rd party keys, is an unnecessary weakness in the message format that
scales too well for the attacker.


> >Instead, let's leave message recovery up to the implementors of
> >individual applications, as an added feature not part of the official
> >open-pgp standard.  Those who sell into markets where such features are
> >desired can add them.  The rest of the world will not have to be forced
> >to go along.
>
> No one is forceing anyone to do anything here. No one is calling for MUST
> CMR key generation, no one is calling for MUST CMR implementation, all
> that is being requested in the spec is the definition of the CMR tag in
> the key. If you don't like it don't use it!! I think this falls in line
> with letting those who wish to implement message recovery to do so and
> those who do not don't.
>

PGP Inc.'s SMTP policy enforcer shows quite clearly how use of the CMR keys
can be (and is being?) required.  The tags should thus not be defined as
part of the official standard, as this leaves a wide opening (already being
exploited?) for forcing encryption of messages to 3rd party keys.

This unnecessarily weakens the security of the standard.  Message recovery
can and should be done only for those markets that need it, in the clients
they run, to avoid forcing the rest of the world to share the increased
risk.  Message recovery features thus need to be outside the open-pgp
standard.


Richard