IETF policy on refusing to allow politics to weaken protocols (Re: Why Adam Back keeps politicizing technical issues)

[Adam Back <aba@dcs.ex.ac.uk>]

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`