Hey Tom,
\nI appreciate you taking the time to write out your ideas. I share many of the same interests and have worked to accomplish some of the items on your list. That said, I think many items on your list have caveats that prevent their development and deployment, or create unintended side effects. I picked out a few and shared my thoughts. I would not fund many of these projects. I don\u2019t think many would work and I don\u2019t think they solve many problems that users have.
\nSecure Mobile Encryption with a PIN\nGoogle tried this with Project Vault, and it had many caveats: 1) Users must purchase or modify their device 2) Each participant must have the device at the time communication occurs 3) Using a 3rd party device makes you a target for suspicion 4) Integrating it right relies on the vendor (Google) since they control the core apps and the operating system. Google owns this problem, it is theirs to solve.
\nRemote Server Attestation of OSS Server Configs\nSecure Boot is technically immature and complex. I would only trust the largest security teams with the best funding to get the minor details correct. The organizations you want to develop and deploy this technology are Amazon, Google, or Microsoft in their public clouds, not a third-party with seed funding from OTF.
\nOpen Source TPM-Backed, Authenticated Disk Crypto\nDisk crypto is tightly coupled with the operating system. Only Apple, Google, or Microsoft can solve this problem. I would bet money we see a \u201cFileVault 3\u201d in macOS 10.13 based on APFS.
\nAuthenticated WebRTC Video Chats\nThanks for pointing out Tuber, our self-hosted videochat application. OTF funding for future development of Tuber was denied.
\nMic and Audio Cutoffs\nYou become a target for surveillance by using add-on privacy hardware. The only way to deploy such a technology in a safe manner is to deploy it by default, through an OEM, to everyone. Similar criticism was leveled at Snowden\u2019s cellular kill switch which required extra hardware.
\nMore Better Faster Compiler Hardening\nAs someone who keeps up on this field, I disagree that performance is a problem. Performance impacts of the latest compiler-inserted exploit mitigations are negligible. The issue is usability. How hard is to turn the feature on? We will explore this topic on blog.trailofbits.com next week.
\nEncrypted Email Delivery\nKey pinning is the only feasible idea here, but the true solution is to move away from e-mail entirely. Email will never be reliably encrypted. It should die, so we can make a fresh start elsewhere, whether it is Signal (which can handle 100mb attachments!) or Matrix or another solution.
\nEncrypted Email Databases\n\u201cWhy haven't we made some subtle improvements to this design and deployed it? Why are we letting the perfect be the enemy of the good?\u201d Because crypto is only effective when it\u2019s perfect.
\nIntel SGX Applications\nI agree in principal, however, racing to write SGX container apps before the underlying technology is secure would be premature. In short, the host operating system maintains the page tables for enclaves which exposes a fundamental vulnerability for all containers apps. An attacker can have the host operating system page everything out of the enclave and then watch an application make calls into it. They get a page-level trace of what the application in the enclave is doing and, in many contexts, this is incredibly bad. It tells you what code was executed in the enclave and what data was accessed, but maybe not precisely what the data is. This side channel provides an attacker way more visibility than they ought to, sort of like being able to trace power leads on a physical HSM. Intel could make the enclave take ownership of physical pages and remove them from the host operating system entirely. Doing so would entirely shut down this attack, however, at the expense of wiring in memory. Existing mitigations for this attack are, in general, not effective.
\ngrsecurity\nNot a solution. It raises a static bar for exploitation and waits for an attacker to successfully exploit it. Simply applying grsec everywhere does not change the fundamental problem.
\nServices Hosting\n\u201cBut who would you trust more to fight against legal requests: Google.... or the ACLU? Google... or the EFF?\u201d I don\u2019t see what problem this solves. Besides, Google has a lot more money, lawyers, and security engineers than both the EFF and the ACLU.
\nXMPP Chat Relay Network\n\u201clet's create a volunteer, community run network of XMPP servers that allow anonymous registration.\u201d So, email but with XML this time? You create the exact same problems, like spam, and don\u2019t improve upon any of the downsides of email with this approach.
\nSources of Funding\nI wrote and submitted five applications for funding to the OTF, including one related to the WebRTC idea you proposed above. All were denied. OTF\u2019s mission is not broadly focused on foundational improvements to internet infrastructure. They need technology that makes a measurable impact on the lives of at-risk people around the world. Similarly, other non-profits I have spoken with have been unwilling to fund efforts that are purely technology improvements.
\nMOSS is a bright light in this area. They are focused more on the tech and understand the value of foundational improvements. However, it is never a bad thing to concretely describe how users will benefit over existing solution when making a proposal to them.
\nPotential Improvements\nI think writing a list of technology improvements is not productive primarily because it is disconnected from the value that users get from them.
\nIf you make a list like this, you should make it target or goal-centric. If you did that, you would frequently discover that what you are asking for already exists in one form or another. Then, you can look at how to improve that thing, whatever it is. For example, \u201cLet\u2019s make a secure XMPP network.\u201d This is a solution looking for a problem\u2026 what\u2019s the problem? The problem is that Alice and Bob are out there, they know each other, and they want to talk over a distance. What can they do today? Well, there\u2019s Signal and Facetime Audio. What\u2019s wrong with these solutions that warrants tearing them down and starting over?
\ngrsecurity and compiler mitigations are another one where the case is a little clearer: \"I've got a computer I'm using and I want to be the only one using it.\" Is it short-term (Tails) or long-term (my Macbook)? Does it store data at rest that I don't want to lose? Do I connect it to the internet? Do I have to? Do I carry it around or does it stay locked in a cage? etc.
\n-Dan
"},{"author": "Tom", "email": "31e32ecb7309ad47e1ecdd34f4c26529", "website": "", "submitted": "2017-02-15 10:37:21", "comment": "Thanks so much for the detailed and insightful response! I tend to agree with most of what you said. (Especially thinking about 'solutions looking for a problem'. The XMPP thing for example is pretty ridiculous on its face but I couldn't resist not throwing it in.) Some individual responses:
\nCompiler Hardening - The push back I've seen for CFI (email conversations) and CFG are both performance 'gosh can we pay that cost?' related. I don't agree with it (obviously I think its worth it) but that's what I deal with on the daily.
\nThe page tracing SGX stuff is definitely a good attack vector. (But it only applies to enclaves that I want for features, not for enclaves that I want to use to neuter SGX itself.)
\nThe comment you give for grsecurity applies to almost everything, doesn't it? CFI, ASLR, DEP, whatever. It doesn't change the fundamental problem but making it harder to exploit things is valuable, which is why we do it everywhere...
\nThe comment you make about OTF is well said. (I've been involved with CII longer than OTF, and I think CII is probably closer to your work.)
"},{"author": "Kevin Gallagher", "email": "9f5abfc24f5aacd795bb623ebb6833e2", "website": "https://cointel.pro", "submitted": "2017-03-26 17:46:08", "comment": "I liked this post a lot; thanks for fleshing out your ideas. Just wanted to note you said StartSSL (a company when I think you meant STARTTLS. Also, FYI grsec can now be installed easily in Debian unstable: apt-get install linux-grsec-base. -@ageis
"}] }