Subject: Re: Server decryption / signing (was RE: Encrypting RFC822 headers in S/MIME or PGP/MIME messages)

From: William Ottaway <[email-masked]>
Date: Mon, 28 Sep 1998 17:00:48 +0100

At 16:00 25/09/98 -0500, William H. Geiger III wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>In <[email-masked]>, on 09/25/98 
>   at 01:47 PM, "Blake Ramsdell" <[email-masked]> said:
>
>>> -----Original Message-----
>>> From: William H. Geiger III [mailto:[email-masked]]
>>> Sent: Friday, September 25, 1998 1:22 PM
>>> To: Steve Hole
>>> Cc: Ned Freed; [email-masked]; [email-masked]
>>> Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
>>> 
>>> In <[email-masked]>, on 09/18/98 
>>>    at 10:55 AM, Steve Hole <[email-masked]> said:
>>> 
>>> >Also there has been discussion many times in the past of 
>>> having "proxy 
>>> >security handling" for IMAP servers where the IMAP server handles
>>> >decoding encrypted messages on behalf of the client and sending the
>>> >decoded content over an encrypted data connection to the 
>>> client.   Note
>>> >that this is not a  real situation now, but there are lots 
>>> of reasons for
>>> >people to want this  behaviour in the future and it continues to be
>>> >discussed.
>>> 
>>> IMHO this is *not* a good idea.
>>> 
>>> The purpose of using end-to-end encryption is to avoid the 
>>> use of unknown
>>> 3 party systems to relay encrypted data. Decrypting on the server then
>>> re-encrypting via different means devalues the original encryption and
>>> brings unnecessary exposure of the raw data. It would also 
>>> require that
>>> the decryption keys of the recipient be stored on the server adding an
>>> added level of insecurity.
>
>>The originator can encrypt for the server, which will then decrypt the
>>message and send it on to the recipient.  The server does not need to
>>have the recipient's private key -- in fact, the recipient may not have a
>>keypair at all (only the server).  The value of the original encryption
>>is to keep things protected at the message level over the public
>>Internet, and then place the plaintext on the local trusted network. 
>>This allows for organizations to implement message-level security without
>>having to put cryptography on the individual desktops.
>
>I don't like it. It goes against the concepts of end-to-end encryption. If
>I want to send an encrypted message to someone, I want *only* that
>recipient to be able to read that message, not someone down in MIS, not
>some mail clerk, or god knows who else that has access to the local
>network. This is the whole point of end-to-end encryption, I don't have to
>"trust" any network security, all I have to trust is my local security and
>my recipient's local security. While not putting encryption on the users
>desktop may be a selling point to the pointy haired bosses it is a
>downgrade of the encryption protocols and not a direction I would
>recommend.
>
>>> While I have played with "proxy security handling" in the 
>>> past it has been
>>> for out-bound encryption, in-bound signature verification, and policy
>>> enforcement. In-bound decryption & out-bound signing should 
>>> never be done
>>> by anyone but the owner of the private keys.
>
>>The server can have private keys also, and the semantics of the outbound
>>signature is that the server (or organization) signed the message, not
>>the individual.
>
>IMHO this is poor practice. Corporate documents should be signed by the
>author(s) of those documents not some universal company signature. Even
>with corporate entities, one still needs to tie back to individuals in the
>corporation during communications. I may be missing something here, but I
>don't see the value of a generic corporate signature.
>
William,

Have you read draft-ietf-smime-domsec-00.txt?

This contains a section on encryption between servers, and between
individuals and servers. It does not rule out user to user encryption.

I agree with your points on not letting anyone else read your email.
However, organisations want to control the release of messages from their
employees. They want to make sure outgoing messagers do not contain any
sensitive information or viruses. If the sender encrypts his mail using the
recipients key the organisation can not perform any of these checks.

Encrypting and signing using an organisations key rather than an
individuals key reduces the size of the PKI required, and therefore all of
the problems to do with setting up and maintaining a PKI. Plus you are
putting a higher level of credence on the message, its not just coming from
Joe Blogs; its coming from Joe Blogs organisation.

Server to server encryption and signing reduces the cost of buying and
maintaining encryption facilities on the individuals machines. Plus the
burden on the users machine.

You can still tie a message back to the individual by allowing originator
aswell as domain signatures. Infact I recommend the message being signed by
the originator. This gives the organisation the ability to check the
document has not changed, to control who can release messages and a means
of repudination. 

Bill.
________________________________________________________________
William Ottaway,
L323,                        Tel: +44 (0) 1684 894079
DERA Malvern,                Fax: +44 (0) 1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs,
WR14 3PS

---

From: Adam Back <[email-masked]>
Date: Mon, 28 Sep 1998 18:48:06 +0100

Bill Ottaway writes:
> sensitive information or viruses. If the sender encrypts his mail
> using the recipients key the organisation can not perform any of
> these checks.

Snooping outgoing email for sensitive information isn't a general
commercial requirement.

It is predominantly a government / signals intelligence special
interest goal.

UK's DERA (Defense Research Agency) / GCHQ designed the CASM protocol
to allow snooping on sent and received email.

CASM is partly based on server encryption.  Bill works for DERA
(dera.gov.uk), so I am wondering if he is thinking of CASM in his
comments, in that some of his arguments are couched in terms of a
desire for mail snooping, while others were discussing server
decryption purely in terms of ease of deployment, and adding blanket
super-encryption, security and forward-secrecy for email that would
otherwise not be encrypted.

(CASM includes a form of GACK involving recomputing seed material, for
details see:

	http://www.opengroup.org/public/tech/security/pki/cki/

)

(As an aside, IMO, CASM is not a very elegant protocol: it has many
online messages, uses public key crypto where symmetric could acheive
the same effect with equal security, and has a centralised risk of the
seed material of the root node of the hierarchy being compromised.)

Shared keys or server encryption copes with multiple recipients
needing to be able to decrypt messages (the `sales team' scenario).

Server encryption is useful to augment personal key based security,
and/or to speed deployment of "some" encryption even if not at first
cut personal key based.

I agree with Bill's comments about reduced PKI overhead of server
based crypto, and his ease of deployment comments.

Adam