Prismatic Reflections

Recent public revelations about PRISM, the alleged pervasive collection and analysis of Internet traffic, including various forms of metatdata, are perhaps not surprising to those who recall ECHELON and the background to and . However, public knowledge that such activities are not only possible but allegedly widespread has renewed concerns about Internet surveillance and privacy. It is further alleged that some encryption systems widely regarded as reasonably safe have been compromised (https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html). A call for IETF action has been made at http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying. Bruce Schneier states that "we need open protocols, open implementations, open systems - these will be harder for the NSA to subvert" and suggests that the IETF "needs to dedicate its next meeting to this task. This is an emergency, and demands an emergency response." It is in fact alleged that the surveillance and compromised encryption are not mainly the result of defective standards, but rather of manufacturers and carriers being suborned. Whether it's a real emergency can be debated. Nevertheless, it seems reasonable to discuss what the IETF could do better, in its specifications, to improve the protection of privacy, confidentiality and integrity of Internet traffic. With that in mind, the only purpose of this draft is to record a number of actionable ideas that have been mentioned in recent contributions to the IETF list. "Actionable" means that, in the editor's view, they suggest concrete actions that the IETF could take as part of its work in developing and improving Internet technical specifications. There is no intention to imply that these ideas are good, bad or indifferent, and certainly other ideas have been and will be proposed. Important suggestions may have been missed: these are simply the ones that caught the editor's eye, and they do not represent the outcome of an organised discussion or any kind of consensus. The contributions are presented essentially unedited (but abbreviated or truncated) and without further comment. Where a contribution led to discussion, that can be found in the mailing list archive. This draft might be revised once or twice before IETF 88, but there are no plans for it beyond then. The editor is aware that prisms normally refract light rather than reflect it, but in this case, we are seeing reflections from a PRISM.

We certainly need to apply RFC 3552. (Brian Carpenter) This list (http://www.nytimes.com/interactive/2013/09/05/us/unlocking-private-communications.html) includes a lot of IETF work that probably use MAY instead of SHOULD for some key choices. (Lucy Lynch) S/MIME is almost what we need to secure email. What is missing is an effective key discovery scheme. We could add that and add Ben Laurie's Certificate Transparency and have a pretty good start on a PRISM Proof email scheme. ... So that means that we have to have a key distribution infrastructure such that when you register a key it becomes available to anyone who might need to send you a message. We would also wish to apply the Certificate Transparency approach to protect the Trusted Third Parties from being coerced, infiltrated or compromised. Packaging the implementation is not difficult, a set of proxies for IMAP and SUBMIT enhance and decrypt the messages. The client side complexity is separated from the proxy using Omnibroker. ... We do have several areas where we could make significant advances however: 1) Technical improvements to TLS such as recommending sites turn on PFS by default and remove weak ciphers. 2) Stop sending authentication cookies in the clear whether or not they are sent inside an encrypted tunnel (). 3) Fix the missing 5% that stops people using secure email. We have PGP that has mindshare and S/MIME that has deployment and both are too much trouble for most IETF people to use, let alone the typical Internet user. We can and should fix that. (Phill Hallam-Baker) Also see . Encrypting everything on the wire raises the cost for untargeted mass surveillance significantly. And that is what it is all about. And best is of course if this can be end to end, though hiding metadata requires either something onion like or transport encryption by layers below said metadata. (Martin Milnert) I think we can do more. Some examples: * we're having a discussion in http 2.0 work whether encryption should be mandatory * the perpass list has talked about understanding better where fingerprinting is an issue with IETF protocols * maybe it would be time to start having specs say that implementations must refuse older, weak algorithms * we could do more analysis and review to understand where the weak points and development opportunities are -- too early to say there are none (Jari Arkko) I just recently produced a short writeup about the efforts related to this topic ongoing at the last IETF meeting on my blog: http://www.tschofenig.priv.at/wp/?p=993. (Hannes Tschofenig) One way to frustrate this sort of dragnet surveillance would be to reduce centralization in the Internet's architecture. Right now, the way the Internet works in practice for private individuals, all your traffic goes up one pipe to your ISP. It's trivial to tap, since the tapping can be centralized at the ISP end. [If the] IETF focused on developing protocols (and reserving the necessary network numbers) to facilitate direct network peering between private individuals, it could make it much more expensive to mount large-scale traffic interception attacks. (Adam Novak) There is a whole bunch of stuff we can do to make transit traffic less observable. In other words we can modify things so the only think you know about a packet is where it is going, not what it is or who it came from. ... Clearly, we have a lot of specification work ongoing in different areas that helps to mitigate various security vulnerabilities. This ranges from recent work on XMPP end-to-end security (as in ) all the way to the recent RTCWEB discussions on using DTLS-SRTP as a key management protocol.(Stewart Bryant) We setup the perpass list as a venue for triaging specific proposals in this space. A few weeks in, we have that tries to describe a threat model that matches the recent revelations, and that could be a good reference when folks are developing protocols. We have found volunteers to write a draft for a BCP on how to use perfect forward secrecy in TLS, more common use of which (we still think) would mitigate a bunch of the ways in which TLS traffic could be subverted, given various forms of collusion/coercion. (Stephen Farrell) If we took protection against MitM attacks seriously, we would be using ZRTP for RTCWEB instead of DTLS-SRTP. See . (Alan Johnston) I think we need to separate the concept of end-to-end encryption from authentication when it comes to UI transparency. We design UIs now where we get in the user's face about doing encryption if we cannot authenticate the other side and we need to get over that. In email, we insist that you authenticate the recipient's certificate before we allow you to install it and to start encrypting, and prefer to send things in the clear until that is done. That's silly and is based on the assumption that encryption isn't worth doing *until* we know it's going to be done completely safely. We need to separate the trust and guarantees of safeness (which require *later* out-of-band verification) from the whole endeavor of getting encryption used in the first place. (Pete Resnick) One thing that would be helpful is to encourage the use of Diffie-Hellman everywhere. ... Using TLS with DH to secure SMTP connections is valuable even if it is subject to MITM attacks, and even if the NSA/FBI can hand a National Security Letter to the cloud provider. (Ted Ts'o) And I think that one of the more important things we can do is to rethink UIs to give casual users more information about what it going on and to enable them to take intelligent action on decisions that should be under their control. There are good reasons why the IETF has generally stayed out of the UI area but, for the security and privacy areas discussed in this thread, there may be no practical way to design protocols that solve real problems without starting from what information a UI needs to inform the user and what actions the user should be able to take and then working backwards. (John Klensin) What we should probably be thinking about here is: - Mitigating single points of failure (IOW, we _cannot_ rely on just the root key) - Hybrid solutions (more trust sources means more work to compromise) - Sanity checking (if a key changes unexpectedly, we should be able to notice) - Multiple trust anchors (for stuff that really matters, we can't rely on the root or on a third party CA) - Trust anchor establishment for sensitive communications (e.g. with banks) (Ted Lemon) We could be telling the public about the protocols that we designed 10, 15, and even 20 years ago. Some of which even have rather widespread implementation, but seem to have zero use. (S/MIME is in every copy of Outlook and Thunderbird, AFAIK) What would the spam situation be like if 90% of emails were regularly signed back in 1999? Yes, and DKIM can sign message bodies now too. We should be telling people about it. Use this stuff ourselves!!!! (Michael Richardson) In other words, the IETF needs to assume that we don't know what will work for end users and we need to therefore focus more on processing by end systems rather than end users. (Dave Crocker) In effect, DANE exchanges one trust model for another. I happen to believe that the damage risque is lower with DNSSEC + DANE than the traditional "any CA can issue a certificate for any domain name" setup. ... Audit and open source seem to be good starting points. (Mans Nilsson) There was actually a proposal a couple of weeks back in the WG to encrypt all traffic on the inter-xTR stage [in the LISP protocol]. (Noel Chiappa) Review all key length recommendations and make them larger and strongly recommend not using any shorter than <foo>. While the reports are probably true that NSA can break common algorithms, making the key length longer will make it harder to do it in scale. Move to real end to end security where key are shared via a different communication path. Perhaps like PGP. Remove man in the middle attacks on common protocols like SSL/TLS. This is a giant problem, some people sell products that view this as a feature (including my employer). This is part of a general problem of middle boxes that change content, but can be fixed if we make sure they can't alter the secure content. Make everything run over secure paths. Even things like the DNS and ICMP. Perhaps if we can secure ICMP, it will mean that middle boxes will stop dropping things like PMTU discovery packets. (Bob Hinden, in private mail, included with permission). It is a shame that this opportunity was not taken to highlight the need for authentication. Having a totally secure channel with perfect encryption is of little value if the other end of the channel is a hostile power. (Tom Petch)