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:[email protected]] Sent: Monday, June 01, 2015 10:49 PM To: Nordgren, Bryce L -FS; [email protected] 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:[email protected]] On Behalf Of Nordgren, Bryce L -FS Sent: Monday, June 01, 2015 10:42 AM To: [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]> 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
_______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
