From: Adam Back <aba@dcs.ex.ac.uk>
Date: Thu, 23 Oct 1997 04:45:37 +0800
To: jon@pgp.com
Subject: Re: shared keys, proxy encryption (was Re: PGP 5.5 CMR/GAK: a possible solution)
In-Reply-To: <3.0.3.32.19971022120251.00bf7b30@mail.pgp.com>
Message-ID: <199710222033.VAA05775@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Jon Callas <jon@pgp.com> writes:
>    The CMR feature in pgp5.5 isn't so far intented to cope with this
>    scenario I think.  That's because pgp5.5 I understand can only
>    generate keys with one CMR request field.
> 
> Well, Adam, you are yet again describing it wrong. You can put in N of
> them. You are right that the 5.5 UI isn't general. 

I did understand that even pgp5.0 standard allows multiple CMR keys,
but I thought that the pgp5.5 UI doesn't allow generation of keys with
more than CMR packet per userid... so sounds like we agree?

One thing I never did get clear is: does pgp5.0 know how to reply to
the CMR denoted extra recipients?

> Also, there's another thing you're not describing correctly. This is not a
> feature of the key -- it's a feature of the user name, and included in a
> user name's self signature. It can be changed at any time, and you can even
> have an ambivalent key that has a username with the CMR packet
> (salesdweeb@foobar.com) and a without it (jblow@foobar.com).

Excuse me, yes, I have been tending to talk about the CMR being
attached to the key, while it is actually attached to the userid, of
which there can be many.  I tended to view this as a valid
simplification, because, if I understood correctly, the pgp5.5
business suite allows an administrator to configure the pgp5.5 client
which employees will be using to enforce that there _will_ be a CMR
packet on all userids?  And also most users are likely to have just
one userid.

In other words, I am not denying any of the functionality that it does
have, in being able to be used in privacy respecting ways, but rather
I am describing the most strict settings that the software attempts to
enforce if so configured.  This is still interesting because one
suspects some companies will use it this way, otherwise the
functionality wouldn't have been provided.

>   [...]
> 
> This is why any sort of shared or escrowed keys suck. But in most cases
> it's good enough, because when Fred leaves sales, he loses access to the
> sales computers.

It's not that good because even though he loses access to the
computers, if he retains a copy of the private key, he (or the
competitor he has left to join) can fairly easily obtain the
ciphertext of emails.

Proxy encryption is a good solution to this, if it works for the EG
keys you are using.  Or super encryption or TLS to protect the company
internal multiple crypto recipients.  I am not so much against CMR
crypto recipients per se, as I am against allowing these to show
outside the LAN -- too tempting for governments.

>    Really it seems to me that actually having half a dozen sales droids
>    sharing a key, or being able to decrypt a message because they are all
>    CMR enforced multiple crypto recipients is a security nightmare either
>    way :-)
>    
>    Reckon it would be arguably more secure to have the SMTP policy
>    enforcer decrypt it for them, even.
> 
> Really? You think the SMTP agent should be decrypting? Wow. I don't. 

It clearly could be more secure in some environments, with crypto
illiterate users who can't remember good passwords, or who have
tendency to write them down.  If they're all sharing keys because
they're all part of the same sales team, and the traffic is fairly low
security, I wouldn't discount it out of hand.

> I think that's *really* intrusive, and worse than what we did.

I think that is where we differ ... you focus on privacy principles,
and end up having less security and less resistance to government
abuse.

The above is merely an ergonomics trade off for some environments.  It
doesn't overly help governments snoop, and can be used where
appropriate.

You can still have individual personal use keys, or any other privacy
respecting architecture.  If we were to argue about how systems could
be abused (either government or company abuse) CMR could be abused
with an enforced CMR key on all company keys, and some software to
read all mail before delivery, and approve all mail on the way out.
CMR could also be potentially be abused by governments in passing laws
saying communications keys must have government as a CMR recipient,
and in being able to enforce this by spot checking emails in transit,
and/or via deputised ISPs with binding cryptography used to allow
untrusted fourth parties to check session keys match.

> Interestingly enough, there are a number of people (like Bruce
> Schneier) who have no problem with the additional encryption part,
> but think that the SMTP agent is the work of the devil.

The enforcement part of it is :-)

Multiple encryption over done with too many long term keys also tends
to be a security risk.  Basing recovery procedures on storage recovery
avoids this trend, and avoids the need to have recovery of
communications keys at all for the defined corporate user requirement.

>    Another method of authenticating TLS is to base the authentication on
>    the user's PGP WoT.  Include authentication information to the
>    delivery agent which is capable of TLS, which is also exchanged inside
>    the encryption envelope.  (Eg. transfer an authentication symmetric
>    key k1 inside the encryption envelope; send the local TLS capable SMTP
>    hub / SMTP policy enforcer the key k1.  The TLS forward secret key
>    negotiation can then be authenticated using this key.  The remote TLS
>    system can tack the authentication information on to the delivered
>    message, in a header, or otherwise, and the recipient can check the
>    authentication).
> 
> Note that the user's WoT is stored in the user's keyring. There's an
> operational problem here. This means that the MTA has to have access to all
> users' pubrings. This is not a good thing, to my mind.

No, I think you misunderstood the above.

MUA sends X-MTA-authentication only if the MTA is TLS aware, then it
sends:

To: fred@acme.com
X-MTA-auth: 12345678

-----BEGIN PGP MESSAGE-----
blah blah
-----END PGP MESSAGE-----

the local MTA strips out X-MTA-auth info.  Local MTA does a DH key
exchange with the remote MTA.  Local MTA encrypts with symmetric
cipher (say IDEA or something) the hash of DH parameters and
negotiated DH key with X-MTA-auth key, and puts back in header:

X-MTA-auth: abcd1234abcd1234abcd1324abcd

The receiving MTA leaves that alone, but adds a line telling the MUA
the DH key hash:

X-MTA-key: 567856785678

The MUA hands the X-MTA-auth line to the pgp implementation, together
with the encrypted message.  You have another packet inside the pgp
encryption layer which tells the receiving MUA the sending client's
info... and PGP can check the authenticate the DH key exchange after
the fact.  If there is a MITM you will know about it.

Neat because it doesn't require separate key infrastructure which
always ends up having less meaning to the user being down at the mail
hub level.  And yet you have real interactive perfect forward secrecy.

>    It is possible that
>    there is an unstated perceived user requirement, that the messaging
>    standard be able to allow third party access to the communications
>    traffic directly.
> 
> Nope, that's not what we're arguing for. 

OK, thanks.  I'll stop speculating on that one then.

> What we're arguing for is an alternative to key escrow -- the kind
> where your employer keeps your secret key just in case they need it.

Please read:

	http://www.dcs.ex.ac.uk/~aba/cdr/

It also avoids key escrow for communication keys, and allows separate
personal and company use storage keys, makes recommendations for
sender and receiver statement of intent about plaintext handling, has
more ergonomic recovery options, and allows more secure more frequent
communication key updates.

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`