Coming into the discussion mid way through and answering various points raised in emails, etc. in one post rather than trying to fisk.
As far as action items go, I think we should punt and have a scheduled discussion in London. This is important and we need to get it right.
Some discoveries from spending four years building really end-to-end systems that may be relevant:
0) Don't consider practicality
I have running code that does things people say is impossible. Leave aside assumptions of what is possible based on 1990s cryptography or what can be done with SMTP and/or TLS.
1) We may need to recognize degrees of compliance.
If we view end-to-end as a monolithic set of criteria, nothing built on legacy protocols will ever meet them. But if we have a checklist, they might meet 2/10 today and be able to get to 5/10 in the future and that can be a win.
2) Distinguish Routing Meta-Data from Content Meta-Data.
Lots of responses of the form 'but the meta-data is visible'. Mail delivery services only need to see some of the meta-data and maybe less of that than what people assume. The original design for Mesh Messaging had messages being sent to an account address. Then I realized that the service doesn't need to ever see the human readable address, all they need is the unique account identifier formed from the root public signature keys.
3) Web browsers can be upgraded
I am not at all keen on trying to make Web Mail end to end secure because there is simply too much code and too much else going on in the browser. I know about process isolation, etc. etc. but my, what an attack surface you have there. And as STUXNET taught us, airgaps tend to fail because it is really difficult to insist on the separation. So what hope...
That said, we could certainly outfit Web browsers with the ability to securely read OpenPGP and S/MIME encrypted Web Mail. The challenge then being making sure no other site can get hold of the private keys or the ability to use them.
4) The end might not be the end
My browser (PHB) has the ability to perform decryption of documents in the browser itself. So we can encrypt a set of documents, put them on a Web site and authorized users can view them as normal, no change to the user experience unless they try to view a document they are not authorized to see. And because the scheme supports threshold decryption, authorizations can be added or removed dynamically without modification of the content.
OK, so great win, right? Well not necessarily because what do we do if someone writes a malicious _javascript_ that reads documents from a site in the user's browser and then breaches them? This is not a completely new vulnerability, but the proposed use case ups the risk model.
So we also need to consider what happens to the data after it is read. There is a malicious version of the TOR browser being heavily promoted by Chinese bots which doesn't have a backdoor perse. The browser itself does not send anything to anyone. Instead, it keeps a list of the sites accessed, the content downloaded on disk in a place where the state actor written malware can find it.
5) Data availability is also a security concern
One of the big mistakes I think we made during the cryptowars was to dismiss the need for key escrow completely. I have several Terabytes of extremely valuable (to me) data. I have that data stored at offsite locations in case of a disaster. But I can only encrypt that data if I am absolutely, completely sure of being able to recover it.
A government mandated backdoor is certainly not a key escrow system. If my house burns down, would Team Louis Freeh have helped me recover the data? Of course not.
So rather than saying "backdoors" ... are often presented as additional design features under terms like "key escrow". I think we need to say that a backdoor is NOT a key escrow system, these are two entirely separate functions and in most cases distinct technologies.
6) What is a third party?
We make a mistake when talking about Alice and Bob because it is not always about just Alice and Bob. Consider the cases
A) Bob, Alice's lover
B) Bob, Alice's customer support agent
C) Bob, Alice's broker
Bob himself is only the real endpoint for case A. In case B, Alice wants the conversation to seamlessly transition to another service agent if Bob falls under a bus. In case C, there is law in most jurisdictions requiring the conversations be recorded for regulatory purposes.
Point is that Bob's employer isn't really a third party in this conversation.
Case C is interesting because while there is a requirement to log the entire conversation, there are also strong confidentiality requirements on that data afterwards and the need for continued controls.
7) Who controls key accreditation
Given the amount of hostility I have received over the years for supporting the CA based model of PKI to enable E-Commerce, I am rather surprised at the readiness with which so many people have accepted models in which the curator of a walled garden is ultimately responsible for management of keys.
My 'end-to-end' messaging application insists on updating itself every couple of weeks. It is really not practical for me to use an app other than the one the service provider uses and so there is absolutely no way for me to know what is going on in the app. Uploading source code to github means nothing because I have no way to know if my app matches that code.
So ultimately, I am relying on the operator of the service to shut it down rather than submit to a demand to slip in a backdoor. And the attack may come from a state actor who works through bribery and/or extortion rather than court orders.
Complacency on this issue is putting the staff of these service providers and their families at serious personal risk. When it comes to espionage, 'do this and your mother will get treatment for her heart condition' actually means 'if you don't do it, not only will she not get the operation, she will fall out of a hospital window if she manages to survive without it'. And that case isn't even the worst of them.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
