The degree to which the send wants to retain control over the policies on subsequent messages is a policy for the sender. So far I have seen three types of binding for subsequent messages.
1. None. This is the case where the need to bind policy ended on delivery to the recipient. This is the case with scenarios like business to consumer where it's the consumer's data e.g. a statement or health record. 2. Append allowed. This is where the original policies are preserved and subsequent messages could have a policy appended (a logical policy AND). This is the case with scenarios like replay all for business to business where the subsequent message has the original content plus some new content. The user replaying to the original message needs to add their policy because they added some sensitive or regulated content. 3. Alternate allowed. This is where the original policies are preserved and subsequent messages could have an alternate policy applied (a logical policy OR). This is the case with forwarded business to business where the originator is delegating to the recipients the ability to provide an equivalent policy for its community of interest. The first is easy to deliver since it has no expectations on the client. The latter two are a higher bar and put some level of trust in the client. In these case over time you will likely want some claim about the state of health of the client before you release the decryption key. From: Whitlock, Stephen [mailto:[email protected]] Sent: Tuesday, April 12, 2011 6:31 AM To: Trevor Freeman; Stephen Farrell Cc: [email protected] Subject: RE: [plasma] why not web portal mail? So, would Plasma allow me to create/modify a set of allowed recipients to a conversation conducted over a public network by just changing policies on the messages? And would this work across different vendor's e-mail systems? Steve W From: [email protected] [mailto:[email protected]] On Behalf Of Trevor Freeman Sent: Monday, April 11, 2011 5:02 PM To: Stephen Farrell Cc: [email protected] Subject: Re: [plasma] why not web portal mail? Hi Steve, -----Original Message----- From: Stephen Farrell [mailto:[email protected]] Sent: Friday, April 08, 2011 11:34 AM To: Trevor Freeman Cc: [email protected] Subject: Re: [plasma] why not web portal mail? Hi Trevor, On 06/04/11 20:33, Trevor Freeman wrote: > Stephen Farrell asked why not use Web portal mail? Why do we need to > develop plasma? > > I don't think we concisely answered that question in the BoF and it is > an important data point. Thanks for trying now. > The web portal mail products are used where there is no way to > securely deliver sensitive mail to a recipient outside the sender's > organization. > The message is held within the sender's organization and a > notification email is sent to the recipient. The notification email > contains a HTTPS URI to the original message with the sensitive content. Right. > This model work Ok if it is bilateral communication e.g. > doctor-patient where you want to reply to the sender. This has been deployed > with my > healthcare provider and we can exchange messages. Well, its also works fine for announcements, i.e. 1:N messages. [TF] Agreed. > However the > notification email are very generic by design so it hard to find > specific messages in your inbox other than by date and time sent. It > also means useful features like inbox search don't work as you only > have the notification message in your inbox. True. However, does that mean that you'd expect the UA search function to be plasma-aware? If not, then won't the sensitive information be vulnerable in whatever search DB the UA uses? Maybe that's a question of defining the trust boundaries for this, but given that the search may be on an IMAP server its possibly complicated doing that in a secure way. [TF] Yes I expect search engines to become Plasma aware just as search engines have become aware of other encrypted content types. The search engine does not necessary need unrestricted access to content and the content indexed is by definition potentially sensitive so have to be controlled. However that process is a local UA process so is not in scope for Plasma. However the fact that all the user content is in their inbox makes it a tractable problem. > This model fails totally if it's multilateral communication where you > want to reply all or forward to messages. Hmm. So that'd imply that forwarding etc. is an important part of the proposed work? It strikes me that that's one of the weakest aspects of generic s/mime (just from personal experience, its not something I've gone out of my way to test). There'd also be some pretty complex policy calculations to make to figure out what can be forwarded to whom, I assume, so this seems like a fairly complex area. [TF] Not just forwarding - reply all is just as important as we have demonstrated with this thread. One of the value propositions for email is the flexible, multiparty nature of the asynchronous communication whereby groups of individuals can be part of a conversation and any recipient can participate in the thread or can spawn new threads just as we are doing here. The objective that Plasma brings is the desire to maintain a degree of policy enforcement to the process when the content of the message is either sensitive or regulated. What if, as part of my reply, I wanted to inject some information which was Microsoft confidential and was being shared under respective non-disclosure agreements? The aim of Plasma would be to allow me to add a policy check before the decryption key to my reply was disclosed to recipients to ensure every recipient was in an organization which had a current legal agreement in place. This message is using a distribution list managed outside my organization so I cannot determine the exact list of recipients at send time. If the mail list was an S/MIME MLA I could protect the confidentiality of the information so only plasma mail list subscribers can read the content but this does not satisfy the policy requirements of determining if there is a legal agreement in place. > The message never leaves the > originators organization so you cannot originate new message as if it > were from a recipient's organization. This means for business to > business scenario it would hinder the use of email for collaboration. I don't get that at all. But never mind. [TF] I think it's a critical reason for why Plasma. Consider the scenario where this thread becomes sensitive as I suggested above and I was to use a web portal for this reply. That portal would be hosted on a Microsoft corporate server since I invoked the sensitivity clause and you would have received a notification email instead of the actual email. If you were to further reply all or forward that messages the origination point for that message would be from a Microsoft corporate server. The Microsoft server would in turn send out an email notification with a FROM address of [email protected]<mailto:[email protected]> with a url of https:\\mail.microsoft.com\??? This seems a highly dubious pattern which matches the pattern used by phishers and spammers. How could you expect Microsoft to be authoritative for sending mail as someone from Trinity College Dublin to all the recipients on the distribution list? What is the scenario was reversed and we used a web portal in your domain and I still wanted to add some Microsoft sensitive information to the thread. How would your portal know what my corporate rulers were if I were to reply all? > With these limitations I think it's clear that that plasma offers some > significant benefits over web portal email. Not that clear to me I'm afraid. While you're arguing for plasma on this basis, to judge those arguments people would need some kind of evidence that's a good bit better than just an assertion. But I'm sure you guys are working on that. [TF] Yes that is what dialog is about:) S. > > > > *Dr Trevor Freeman* Senior Security Strategist > > *End to End Trust Team* > <http://www.microsoft.com/mscorp/twc/endtoendtrust/default.mspx>** > > *Microsoft Trustworthy > Computing*<http://www.microsoft.com/mscorp/twc/default.mspx> > > > > > > _______________________________________________ > plasma mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/plasma
_______________________________________________ plasma mailing list [email protected] https://www.ietf.org/mailman/listinfo/plasma
