Re: [Endymail] FW: Group/Enterprise encrypted email

[Trevor Freeman <[e-mail]>]

Hi Bryce,

What you propose is very similar to the Plasma work. The Plasma server
functions like a EKG as you describe. We generalized the model more so we
made authentication to the Plasma server via user tokens so it is possible
to support a broader set of authentication mechanisms and authentication
levels e.g. Facebook or Google+, as well as PIV cards.  Since we support
user tokes we can also do Attribute Based Access Control if the message
contents warrant e.g. if the message has ITAR material.  There were a number
of compares built a POC to show this works and interoperates. 

Here is the requirements document if you are interested.

Doing late key binging via an EKG does have a number of advantages over
early key binding. It is generally much more forgiving. It does not requires
everybody to have encryption keys at send time. It scales better if you have
a large number of recipients. It also does not require recipient key escrow
to prevent data loss if you lose your encryption key.  This main issue is
the security and scope of the EKG key or keys. 

Here is the draft if you want to read more.
https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/

 

Trevor

 

From: Endymail [mailto:[e-mail]] On Behalf Of Nordgren,
Bryce L -FS
Sent: Monday, June 01, 2015 10:42 AM
To: [e-mail]
Subject: [Endymail] FW: Group/Enterprise encrypted email

 

I was directed to this list because I posted the following to [kitten]. I
looked at the archives here, and it seems that my proposed email key
gatekeeper (run by the entity providing the email account) may solve the key
distribution problem for transit, both for point to point ops as well as
mailing lists.

 

No promises. It's not like I spend my life thinking about this stuff.

 

Bryce

 

From: Nordgren, Bryce L -FS 
Sent: Friday, May 29, 2015 4:36 PM
To: [e-mail]
Subject: Group/Enterprise encrypted email

 

This is a "what if" message, centered around trying to make email encryption
as painless as email signing. I want to be able to encrypt an email message
once, no matter how many recipients there are. An enterprise should be able
to decrypt employees' email to ensure there's no misbehavior. I want as
little "extra" supporting infrastructure as possible. I also want to
minimize the amount of inter-organizational coordination required.

 

What if sending an encrypted email required clients to contact an email key
gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorized
senders, and releases the decryption key once (only) to each recipient. 

 

Detailed flow:

 

When encryption is desired, the sender's email client formats a key request
to the EKG and signs it using the sender's email signing key. The key
request includes the recipient's email addresses, but not their public keys,
which are unknown. If the EKG is configured to recognize the sender, it
replies with: 1] an encryption key, encrypted with the sender's public email
signing key; and 2] a plaintext copy of the key request, signed by the EKG
itself. The sender then decrypts the encryption key, encrypts the message
and attachments, and attaches the signed key request. Poof. The message is
sent. If the sender's client stores outgoing mail in a "sent mail" folder,
the stored copy must be encrypted using some other means.

 

The EKG-signed key request includes: 1] a unique identifier for the
encryption key; 2] contact info, so recipients can locate the EKG; and 3] of
course, the list of recipients (part of the original key request). 

 

The Sender's organization can decrypt the outbound email at a gateway by
contacting the EKG and retrieving the decryption key (which could be the
same as the encryption key if symmetric, or the other half of an asymmetric
keypair if not.)

 

The recipient's organization (assuming different than sender's organization)
cannot decrypt the inbound email at a gateway. 

 

The recipient's email client detects the EKG's signed key request attached
to the email. The EKG's signature is verified. The recipient's client uses
the recipient's email signing cert to sign the EKG-signed key request, and
sends to the EKG using the contact information provided. 

 

The EKG verifies the recipients' signature. The EKG verifies that the
recipient's certificate contains an email address that is included as a
recipient in the original key request. The EKG verifies its own signature.
The EKG encrypts the email's decryption key using the recipient's public
email signing key, and signs the response. The recipient verifies the
signature (ensuring same EKG signed key request and decryption key request)
and decrypts the message/attachments.

 

If the message is to be stored, it must be re-encrypted in a locally
recoverable fashion, likely with the recipient's credentials. If the
recipient's organization is concerned about decrypting inbound email, the
"locally recoverable fashion" should allow authorized individuals/services
access. The original ciphertext should not be stored after decryption, and
the decryption key must not be stored. Probably best not to get too psycho
over this: the recipient can always cut and paste to some cleartext medium
like word, or take a screenshot. Reasonable assurance that clients keep
things encrypted when they're received encrypted is what we're after.

 

The EKG keeps track of which recipients have requested the decryption key.
Recipients are allowed to request the key once and only once. When all
recipients have requested the decryption key, that key must never be served
out again. The EKG should not re-use encryption keys for subsequent
messages.

 

Clearly, the EKG needs to be just as publicly available as the
organization's mailserver. I do not believe there would need to be anything
special in DNS (no "EKG" records, etc.) To summarize:  The EKG knows nothing
about senders or recipients other than what the certificates tell it.
Encryption keys for email messages are one-time-use, and shared among sender
and all recipients. Recipients get decryption keys by having a certificate
with a matching email address. No extra coordination is involved over and
above the configuration necessary to verify email signatures. 

 

What do you think? Is there an obvious reason this hasn't been done before? 

 

Bryce