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

[Trevor Freeman <[e-mail]>]

Hi Bryce,

The technical specs are in a separate draft. We modified S/MIME but there is
nothing to stop this being applied to PGP.

https://datatracker.ietf.org/doc/draft-schaad-plasma-cms/

 

The Plasma token which is generated by the EKG s bound to the message by a
detached signature. The token has an encrypted payload which can contain
policy dependent metadata such as a recipient list. Not all polices require
a receipt list. 

Plasma does not attempt DRM in that it places no technical obligations on
the receipt when we release the decryption key. SMIME or PGP encryption is
Identity Based Access Control since the sender is authorizing the receipt
based on the identity binding to the key. We were putting email based
content on par with content which was published via the web.  So if you
wanted to send content covered by a policy, you would get the same
protection and policy enforcement as if you published via the web. This is
not about fixing stupid, its more not requiring clairvoyance about every
recipient. 

 

Another aspect is Plasma allows for device attributes so before we release
the decryption key we can requires information about the state of the
environment. That way if the recipient is infected, we can block decryption
which is another plus for late binding. Again his is option so for low
assurance polices you probably not care. 

 

Plasma can also handle multiple polices on a single message so if there were
mixed content, we can selectively release keys i.e. it allows for auto
redaction. 

 

Trevor

 

From: Endymail [mailto:[e-mail]] On Behalf Of Nordgren,
Bryce L -FS
Sent: Tuesday, June 02, 2015 11:53 AM
To: Trevor Freeman; [e-mail]
Subject: Re: [Endymail] FW: Group/Enterprise encrypted email

 

Hi Trevor, thanks for the link.

 

I like the multiple ways to authenticate to plasma servers, and of course
your "late key binding". Sounds so much more professional than my version!
In my quick read, I was not able to locate how I would specify who gets
access to the keys for my message, or whether that was bound to the message
payload. Does the message contain an untamperable list of authorized
recipients?

 

I have some concerns about the DRM, basically that I'd like to see it
factored out into a separate doc. To me, the point of encrypted messaging is
to deliver content to a specified party while preventing others from
snooping. If I have concerns about what that party might do with the content
upon receipt, I shouldn't be sending it to them in the first place. You just
can't fix stupid.

 

But let's say we try to fix stupid. And we specify a perfect message DRM
ecosystem. Screenshots will likely still work. Cell phones with cameras can
always still be pointed at the screen. Are you really comfortable stating
that any situation has a "high", "significant", or even "some" confidence
that policy is enforced when just about anyone can defeat the system with a
keypress? Will users, after they defeat it themselves? Will security
officers?

 

Attachments. The perfect DRM-compliant email client will have to decrypt the
attachment payload and hand it off to the application which recognizes it.
At this point it has been exported from the DRM system and you again must
trust the other party will use it appropriately. Either that, or assimilate
every possible application which can process every possible attachment into
your DRM system. Such a system would be like "Ultraviolet for Everything".

 

The solution to both of these drawbacks is "think before you send", which is
what you should do if you're dealing with sensitive data anyway. Simplifies
the spec immensely, by providing a clear, well defined, easily understood
user responsibility. Even an "Ultraviolet for Everything" approach does not
relieve the user of this responsibility. IMHO, the design of a comprehensive
DRM system for all content is a much different animal than just making sure
the content is delivered reliably and protected from snooping. I recommend
starting with just secure transport and tackling DRM later.

 

Finally, a secure, self-contained DRM system excludes open source software
by definition. If anyone can comment out the "enforcement code" then
recompile, all confidence is low. This is why open source blue ray players
on Linux rely on cracking old codes: no one will give them "good" codes. On
the other hand, secure delivery of "no strings attached" encrypted messages
is something that open source can do very well. Respecting this boundary
line is an excellent reason to split the spec into transport and DRM.

 

Just some thoughts.

Bryce

 

From: Trevor Freeman [mailto:[e-mail]] 
Sent: Monday, June 01, 2015 10:49 PM
To: Nordgren, Bryce L -FS; [e-mail]
Subject: RE: [Endymail] FW: Group/Enterprise encrypted email

 

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