RFC 7687

Report from the Strengthening the Internet (STRINT) Workshop

📅 published December 2015, from ietf

RFC 7687: Report from the Strengthening the Internet (STRINT) Workshop 🦋

Okay bestie, this one is the IAB's report on the STRINT workshop, published in December 2015 as an Informational RFC. Authors: S. Farrell (Trinity College, Dublin), R. Wenning (no affiliation listed), B. Bos (W3C), M. Blanchet (Viagenie), and H. Tschofenig (ARM Ltd.). It's ISSN 2070-1721, and the header doesn't list anything it obsoletes or updates. So it's a record of what happened, not a new spec 💅

Abstract

Okay so STRINT brought about one hundred participants to London for two days in early 2014 to figure out how the technical community, especially the IETF and the W3C, should respond to Pervasive Monitoring 👀 and, more broadly, how to make the Internet stronger against those attacks 💪 The chats covered terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more 🌈 The workshop wrapped up with a few high-level recommendations that people believe could actually be done and could help strengthen the Internet ✨ This is the report of that workshop 📝

Note that this document is a report on the proceedings of the workshop. The views and positions in it belong to the workshop participants and don't necessarily reflect the IAB's views and positions 🫶

Status of This Memo

This is not an Internet Standards Track specification. It's published for informational purposes 🎀

It's a product of the Internet Architecture Board (IAB), and it holds information the IAB felt was worth keeping on the permanent record 📚 Documents the IAB approves for publication are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the details 🧐

Info about the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7687 🔗

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents

1.  Context . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Workshop Goals  . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Workshop Structure  . . . . . . . . . . . . . . . . . . . . .   5
5.  Topics  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
6.  After the Workshop  . . . . . . . . . . . . . . . . . . . . .  20
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
8.  Informative References  . . . . . . . . . . . . . . . . . . .  21
Appendix A.  Logistics  . . . . . . . . . . . . . . . . . . . . .  25
Appendix B.  Agenda . . . . . . . . . . . . . . . . . . . . . . .  26
Appendix C.  Workshop Chairs and Program Committee  . . . . . . .  29
Appendix D.  Participants . . . . . . . . . . . . . . . . . . . .  29
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1. Context ✨

Okay so the technical plenary at IETF 88 [vancouverplenary] concluded that Pervasive Monitoring (PM) is an attack on the Internet 🚨 The IETF has started on the more obvious actions needed to handle this attack. But there are way more complex questions coming up that need more thought before any extra concrete plans can be made 🧠

So the W3C and the IAB decided to host a workshop called "Strengthening the Internet Against Pervasive Monitoring" [STRINT] before IETF 89 in London, in March 2014 🇬🇧 The FP7-funded STREWS project organised the STRINT workshop on behalf of the IAB and W3C 🌸

The main goal was to talk about what can be done, especially by the two standards orgs (IETF and W3C), against PM. That covers existing protocols (HTTP/1, SMTP, etc.) and new ones (WebRTC, HTTP/2, etc.) 💅

The starting point was the existing IETF consensus that PM is an attack [RFC7258]. That text had reached IETF consensus by the time of the workshop, even though the RFC wasn't published yet 🍓

2. Summary 🎀

The workshop was packed. Registration closed once the max capacity of 100 was hit, and more than 150 people wanted in 😭 Around 165 people at the peak listened to the streaming audio too 🎧 The submitted papers (67 total) were generally good quality, and all of them got published, except for a few where authors who couldn't attend chose not to publish 📄

The chairs summed up the workshop in the final session with these recommendations:

  1. Well-implemented cryptography can be effective against PM, and it'll benefit the Internet if people use it more, despite its cost. That cost is steadily dropping anyway 🔐
  2. Traffic analysis also needs to be considered, but the Internet community understands it less well. Relevant research and protocol mitigations, like data minimisation, need better understanding 📊
  3. Work should keep moving on the PM threat model document [Barnes] that got discussed at the workshop. That later work resulted in the publication of [RFC7624] 🧩
  4. Later, the IETF may be in a position to start developing an update to BCP 72 [RFC3552]. It would most likely be a new RFC that enhances that BCP and covers how to mitigate PM and how to reflect that in IETF work 🛠️
  5. The term "opportunistic" gets used a lot as a possible mitigation strategy for PM. The community needs to document definitions for it, because different people use it differently in different contexts 🤔 The community might also build a cookbook-style set of related protocol techniques for developers 🧁 Since the workshop, the IETF's Security area has taken this on, and most recently it's been favouring the generic term "Opportunistic Security" (OS) [Kent]. That work resulted in a definition of OS in [RFC7435] 👑
  6. The technical community could do better at explaining the real technical downsides of PM in terms policy makers can understand 🏛️
  7. Lots of user interfaces (UIs) could be better at showing security state, though that's a seriously hard problem 😩 There might be benefits if certain dangerous choices weren't offered anymore. But that could take major coordination between competing software makers. Otherwise, some will be called "broken" by users 💀
  8. More discussion is needed on how to better integrate UI issues into the IETF and W3C processes 🫶
  9. Examples of good software configurations that people can cut-and-paste for popular software can help. This isn't necessarily standards work, but the standards orgs might help and work with the people making that package-specific documentation 🌈
  10. The IETF and W3C can do more so that default ("out-of-the-box") protocol settings better protect security and privacy 🔒
  11. Captive portals [Captive] and some firewalls can and should be distinguished from real man-in-the-middle attacks. That might mean setting common conventions with makers of such middleboxes, and it might also mean developing new protocols. The incentives for deploying those new middlebox features might not line up though 🙈

5.1. Opening session ✨

okay so the first session was all about the goals of the workshop 🎀 people asked what a real fix for pervasive monitoring (PM) could even look like. some ideas: take a critical look at what metadata is actually required, figure out whether old, less secure devices can be swapped for new ones, grab the "low-hanging fruit" (stuff that can get fixed quickly and easily), and decide what level of security is "good enough" 💅 bestie, a good solution might be one that works for 90% of people or 90% of organisations, and that's honestly a very valid vibe check.

some participants felt like we need standards so people can tell whether their systems meet a certain level of security 🫶 and those standards need easy-to-remember names, so a buyer can instantly see that a product "conforms to the named intended standard." iconic, honestly 😭

5.2. Threats 🦋

the way attackers work is kinda different in PM vs. "traditional" attacks. normally you figure out what a bad actor might want to go after, how much it would cost them, and then you defend that specific thing 🔥 but a pervasive attacker has no specific target. they just want to collect everything they can get their hands on 💀 so the math on "what do we lose vs. what does it cost to protect it" is totally different. and unlike someone who's only in it for money, a PM attacker might not care how expensive the attack is (or might even prefer it to be pricey, for "empire building" reasons). not me being shook 🙈

the words we use to talk about threats have to be picked very carefully (this came up in a bunch of sessions, lol), because we need to explain to people outside the technical community what they should and shouldn't do ✨ for example, authenticating endpoints doesn't really "protect against" man-in-the-middle (MITM) attacks. it makes them visible 👀 the attacker can still attack, but they don't stay invisible while doing it. someone on either end of the conversation then has to react to the alert from the system: stop the conversation or find a different channel 🌸

paradoxically 🙃 bigger sites like Facebook, Yahoo, and Google put more effort into securing their services than smaller sites do, but they also make way juicier targets for attackers. avoiding overuse of those big repositories for private or sensitive info might be a useful move, since it raises the cost of collecting for a pervasive attacker. this is sometimes called the target-dispersal approach 🧚

interoperability is another big deal 🍓 when systems don't play nicely together, people end up with messy work-arounds and compromises, and those can introduce vulnerabilities of their own. so improving interoperability needs to be high on the priority list for standards makers, and even higher for implementers. testing (like interop testing) is, to some extent, already part of how the IETF and W3C operate, and the W3C is currently ramping up its testing efforts 💖

5.3. Increase Usage of Security Tools 🔐

the first session on Communication Security (COMSEC) tools asked the big question: why aren't existing security tools used more? 👑

the public key infrastructure that secures HTTP is a really good case study 📚 one problem is that certification authorities (CAs) can issue a certificate for any domain. so a single compromised CA can be combined with a MITM to impersonate any server, which is scary, ngl 😭 and on top of that, the ongoing admin work (requesting certificates, paying for them, and installing new ones) has, over time, proven to be an insurmountable barrier for lots of web site administrators, so they just don't bother securing their systems 💀

some ideas for improving the CA system came up, such as cross-certification of CAs and "certificate transparency" 🌈 which is a public, permanent log of who issued which certificate [RFC6962]. slay.

using other models instead of (or alongside) the hierarchical certificate model could help too 💅 Pretty Good Privacy (PGP) is the classic example of a "web of trust," where people verify the public keys of the people they meet. since there's no innate transitive trust in PGP, it's really only appropriate for small-scale stuff, like a team working on a project together 🫶

another model is "trust on first use" (TOFU), and SSH [RFC4252] uses it quite effectively ✨ on the first connection, you have no way to verify the received public key belongs to the server you're contacting, so the key just gets accepted without further verification 🤷‍♀️ but on later connections, you can check that the key is the same one you saw the first time. so a MITM would have to be there for every connection, including the first one, otherwise they'd get caught by a key mismatch 🕵️‍♀️

this works really well for SSH because people usually use it to talk to a small number of servers over and over again 🎀 if they want, they can also find a separate channel to get the public key (or its fingerprint) 🔑 it might work for web servers used by small groups (like a sports club's server or a company department's server), but it probably works less well for public servers people only visit once or a few times, or for big services where lots of servers might be in use 🌸

there's a similar proposal [RFC7469] for an HTTP header that brings a bit of TOFU into HTTP. key pinning tells HTTP clients that for a certain amount of time after receiving a certificate, they shouldn't expect it to change. if it does change, even if the new certificate looks valid, the client should assume a security breach 🚨

the Session Initiation Protocol (SIP) [RFC3261] can require several different intermediaries at different stages of a communication to handle NAT traversal and policy 🧚 hop-by-hop and end-to-end encryption are both specified, but in practice, lots of SIP providers switch these functions off 🙃 which is understandable, because to overcome interoperability problems they often need to change protocol headers and modify protocol data. some workshop participants argued that SIP would never have taken off if providers hadn't been able to monitor and interfere with communications like that. but of course, that also means an attacker can listen in just as easily 😬

WebRTC is a newer protocol for peer-to-peer communication of video and audio (and potentially other data) 🦋 it reuses a lot of the same architectural concepts as SIP, but there's a reasonable chance it can do better at protecting users, because the people implementing the protocols and offering the service have different goals and interests. in particular, the first implementers are browser makers, who may have different business models from more traditional Voice over IP providers. main character energy 👑

XMPP [RFC6120] has a different kind of problem 🤔 it has encryption and authentication, and the OTR ("off the record") extension even provides what's called Perfect Forward Secrecy (PFS). that means compromising the current communication never gives an attacker enough info to decrypt past communications they might have recorded 🔐 but in practice, lots of people don't use XMPP at all. they use Skype, WhatsApp, or other instant-messaging tools with unknown or no security 💀 the problem here seems to be user awareness. and even though OTR does provide security, it isn't well integrated with XMPP, nor is it available as a core feature of XMPP clients 😭

to increase usage of existing solutions, some tasks were identified 📝 though how those map to actions for, e.g., IETF/W3C isn't clear yet 🙈

  • Improvements to the certificate system, such as certificate transparency (CT).
  • Making it easier (cheaper, quicker) for system administrators to deploy secure solutions.
  • Improve awareness of the risks. Identify which communities influence which decisions and what the appropriate message is for each.
  • Provide an upgrade path that doesn't break existing systems or require that everybody upgrade at the same time. Opportunistic Security may be one model for that 🌈

5.4. Policy Issues and Non-technical Actions ⚖️

previous sessions already concluded that this problem isn't just technical 💅 it's not only about getting the right algorithms into standards, fixing interoperability, or educating implementers and system administrators. there are user interface issues and education issues too. and there are legal issues and policy issues for governments as well 🫶

the public, in general, demands more privacy and security (for their kids, for example) but is also pessimistic about actually getting it 😔 they trust that somebody is making sure nothing bad happens to them, but they also expect to be spied on all the time. the vibes are chaotic, honestly 💀

(perceived) threats of terrorism gave governments a reason to allow widespread surveillance, far beyond what was previously considered dangerous for freedom 🥀

in this environment, the technical community will have a hard time building and deploying technologies that fully counter PM. that means there has to be action in the social and political spheres too 📣

technology isn't the only thing that can make life harder for attackers ✨ government-sponsored PM is indirectly affected by trade agreements and treaties, so it makes sense to lobby for those to be as privacy-friendly as possible 🌸

court cases based on human rights can also influence policy, especially if they reach courts like the European Court of Human Rights ⚖️

in medicine and law, it's super common to have ethics committees, but not so much in software 🙃 so should standards bodies such as the IETF and W3C have an ethics committee? standards like the Geolocation API [w3c-geo-api] have gotten scrutiny from privacy experts, but only in an ad hoc manner. (W3C has permanent groups that review standards for accessibility and internationalisation. It also has a Privacy group, but that one currently doesn't do the same kind of systematic reviews.) 🧐

the Internet-Draft draft-barnes-pervasive-problem-00 [Barnes] (which was included as paper 44) explains that PM doesn't just monitor networks. it also attacks endpoints, turning organisations or people into (willing, unwilling, or unwitting) collaborators 😱 Note: that document later evolved into [RFC7624].

one technical means of protection is therefore to design protocols so there are fewer potential collaborators. for example, a cloud storage provider can't hand over plaintext for content that's encrypted with a key they don't have, and can't hand over names if their client is anonymous 🔐

it's important to tell PM apart from fighting crime 🚨 PM is an attack, but a judge ordering surveillance of a suspected criminal is not. the latter, often abbreviated in this context as LI (for Lawful Intercept), is outside the scope of this workshop 🙌

5.5. Improving the Tools ✨

Okay so an earlier session already dug into why the existing COMSEC tools weren't being used more 🙈. This second COMSEC session picked up from there and asked what improvements and/or new tools we actually need 💅.

The workshop discussion pointed to Opportunistic Security (OS) [Kent] as an important meta-tool for upgrading existing security tech 🦋. The idea is that software gets a little module that tries to encrypt communications whenever it notices the other end can do the same. If the other end can't, the communication just keeps going the old way, no drama. The detailed definition of OS was still being worked out by the IETF Security Area Advisory Group at the time of this workshop [SAAG_list] 📝.

OS would protect against a passive eavesdropper, but it should also allow for endpoint authentication to protect against an active attacker (a MITM) 🛡️. As OS spreads, more and more communications get encrypted (and hopefully authenticated), so there's less and less for an eavesdropper to collect. Iconic behaviour 👑.

Of course, OS could also give a false sense of security 💀. Some connections are encrypted and some aren't. A user might see something like a padlock icon in browsers, but there was agreement at the workshop that such UI features ought not be changed just because OS is being used. Don't make the padlock lie, bestie 🔒.

There's also the possibility that a MITM intercepts the reply from a server that says "yes, I can do encryption" and removes it. That would cause the client to fall back to an unencrypted protocol 😭. Mitigations against this can be to have other channels for finding out a server's capabilities, and to remember that a server could do encryption previously 🧠.

And yes, there's a terminology problem again 🙃. The technical descriptions of OS talk about a "silent fail" when a connection couldn't be encrypted and has to fall back to the old, unencrypted protocol. But it's not actually a fail! It's no worse than it was before. A successful encryption would be more like a "silent improvement" ✨🌈.

That raises the big UI question: how do you explain to a user what their security options are, and, if an error occurs, how do you explain the implications of the various responses? 🤔

The people working on encryption are mathematicians and engineers, and they're typically not the same people who know about UI 🎀. We need to involve the experts. We also need to distinguish between usability of the UI, user understanding, and user experience, because they are three different things 🌸. For an e-commerce site, for example, it's not just important that the user's data is technically safe. It's also important that they feel secure. Otherwise, they still won't buy anything 🛍️💅.

When we talk about users, we also need to distinguish the end user (who we usually think about when we talk about UI) from the server administrators and other technical people involved in enabling a connection 🧚. When something goes wrong (say, the user's software detects an invalid certificate), the message usually goes to the end user. But they aren't necessarily the person who can do anything about it. For example, if the problem is a certificate that expired yesterday, the user's options are to break the connection (the safe choice, but now they can't get their work done) or to continue anyway (and there could be a MITM 😬). The server administrator, on the other hand, could actually fix the problem 🔧.

Encryption and authentication have a cost, both in terms of setting them up and in terms of the time it takes software to do the calculations ⏳. The setup cost can be reduced with sensible defaults, predefined profiles, and cut-and-paste configurations 📋✨. And for some connections, authentication without encryption could be enough, in the case that the data doesn't need to be kept secret but it's still important to know that it's the real data 💜. Most mail user agents (UA) already provide independent options for encryption and signing, but web servers only support authentication if the connection is also encrypted. Kinda unfair, ngl 😤.

On the other hand, as email also shows, it's difficult for users to understand what encryption and authentication each do separately 🫠.

It also has to be kept in mind that encrypting only the "sensitive" data and not the rest decreases the cost for an attacker too 🎯. It becomes easy to know which connections are worth attacking. Selective field confidentiality is also more prone to developer error, because not all developers will know the provenance of the values they're processing 🙈.

One problem with the TOFU model as used by SSH (see explanation above) is that it lacks a solution for key continuity. When a key changes (which can happen, e.g., when a server is replaced or the software is upgraded), there's no way to inform the client 😱. (In practice, people use other means, such as calling people on the phone or asking their colleagues in the office, but that doesn't scale and doesn't always happen either 📞.) So an improvement in the SSH protocol could be a way to transfer a new key to a client in a safe way 🔐🦋.

5.6. Hiding Metadata 🕵️‍♀️

Encryption and authentication help protect the content of messages. Correctly implemented encryption is very hard to crack 🔐. (To get the content, an attacker would rather try to steal the keys, corrupt the encoding software, or get the content via a collaborator. See [RFC7624] for more information on "collaborator".) But encrypting the content doesn't hide the fact that you're communicating at all 😶. This metadata (who talks to whom, when, and for how long) is often as interesting as the content itself, and in some cases the size and timing of messages is even an accurate predictor of the content 👀. So how do you stop an attacker from collecting metadata, when much of that data is actually needed by routers and other services to deliver the message to the right place? That's the real puzzle 🧩.

It's useful to distinguish different kinds of metadata: explicit (or metadata proper) and implicit (sometimes called traffic data). Implicit metadata is stuff that can be derived from a message or is necessary for its delivery, such as the destination address, the size, the time, or how often messages pass 📦. Explicit metadata is stuff like quality ratings, provenance, or copyright data: data about the data. It's useful for an application, but it isn't required to deliver the data to its endpoint 🏷️.

A system such as Tor hides much of the metadata by passing through several servers and encrypting all the data except what a particular server needs to see 🧅✨. Each server knows which server a message came from and where it has to send it, but it can't know where the previous server got it from or where the next server was told to send it. However, deliberately passing through multiple servers makes the communication slower than taking the most direct route, and it increases the amount of traffic the network as a whole has to process 🐢.

There are three kinds of measures that can be taken to make metadata harder to get: aggregation, contraflow, and multipath (see "Flows and Pervasive Monitoring" [Paper4]) 🌊. New protocols should be designed so these measures aren't inadvertently disallowed, e.g., because the design assumes that the whole of a conversation passes through the same route 🚧.

"Aggregation" means collecting conversations from multiple sources into one stream 🥣. For example, if HTTP connections pass through a proxy, all the conversations appear to come from the proxy instead of from their original sources. (This assumes that telltale information in the headers is stripped by the proxy, or that the connection is encrypted.) It also works in the other direction: if multiple web sites are hosted on the same server, an attacker can't see which of those web sites a user is reading. (This assumes that the name of the site is in the path info of the URL and not in the domain name. Otherwise, watching DNS queries can still reveal the name 👀.)

"Contraflow" means routing a conversation via one or more other servers than the normal route, e.g., by using a tunnel (with SSH or a VPN, for example) to another server 🚇. Tor is an example of this. An attacker has to watch more routes and put in more effort to correlate conversations 🕸️. (Again, this assumes that there's no telltale information left in the messages that leave the tunnel.)

"Multipath" splits up a single conversation (or a set of related conversations) and routes the parts in different ways 🛤️. For example, you could send a request via a satellite link and receive the response via a land line, or start a conversation on a cellular link and continue it via Wi-Fi. This again increases the cost for an attacker, who now has to monitor and correlate data traversing multiple networks 📡.

Protecting metadata automatically with technology at a lower layer than the application layer is difficult 😩. The applications themselves need to pass less data. For example, they can use anonymous temporary handles instead of permanent identifiers 🎫. There's often no real need for people to use the same identifier on different computers (smartphone, desktop, etc.) other than that the application they use was designed that way 📱💻.

One thing that can be done relatively easily in the short term is to go through existing protocols and check what data they send that isn't really necessary 🧹. One candidate mentioned for such a study was XMPP 💬.

"Fingerprinting" is the process of distinguishing different senders of messages based on metadata [RFC6973]. Clients can be recognised (or at least grouped) because their messages always have a combination of features that other clients' messages don't have 🖐️. Reducing redundant metadata and reducing the number of optional features in a protocol reduces the variation between clients, and thus makes fingerprinting harder 💅.

Traffic analysis is a research discipline that produces sometimes surprising findings that are little known among protocol developers 🤯. Some collections of results are:

Techniques that deliberately change the timing or size of messages, such as padding, can also help reduce traffic analysis 🎭. Obviously, they make conversations slower and/or use more bandwidth, but in some cases that's not an issue, e.g., if the conversation is limited by the speed of a human user anyway 🙌. HTTP/2, for example, has a built-in padding mechanism 💜. However, it isn't easy to use these techniques well, and the goal is to make messages harder to recognise (as intended) rather than easier. Tricky stuff 🌀.

Different users in different contexts may have different security needs, so maybe the priority can be a user choice, if that can be done without making high-security users stand out from other users 🌟. Although many people wouldn't understand what their choices are, some do, such as political activists or journalists 📰✊.

5.7. Deployment, Intermediaries, and Middleboxes ✨

okay bestie, so secure protocols were usually designed for end-to-end security 🔐, meaning intermediaries cannot read or modify the messages. TLS is the classic example 💅

but in real life, people have more or less valid reasons to want intermediaries 🧚 Companies filter incoming and outgoing traffic for viruses, inspect content to give priority to certain applications, or cache content to save bandwidth.

With end-to-end encryption and authentication in place, these intermediaries only have two choices: use fake certificates to impersonate the endpoints, or get access to the endpoints' private keys. The first one is a MITM attack that's really hard to tell apart from a more malicious one 🙈. The second one obviously lowers the security of the endpoints, because it copies supposedly confidential information and concentrates credentials in a single place 💀

As mentioned in Section 5.2 above, aggregating data in one place makes that place an attractive target 🎯 And for PM, even if the data isn't physically concentrated in one spot, it's under the control of a single legal entity that can be turned into a collaborator 😭

Here's how Web communication with TLS typically works: the client authenticates the server, but the server does not authenticate the client at the TLS layer. (If the user needs to be identified, that's mainly done at the application layer via username and password.) So a MITM (middlebox) could be detected by the client, because of the incorrect certificate, but not by the server. If the client doesn't immediately close the connection (which they often don't), the server may disclose information the user would rather not have disclosed 🫣

One widespread example of middleboxes is captive portals, like the ones on Wi-Fi hotspots in hotels, airports, etc. Even hotspots offering free access often intercept communications to redirect the user to a login or policy page 🛫

When the traffic they intercept is, e.g., an automatic update of your calendar program or a chat session, the redirect obviously doesn't work, because those apps don't know how to display a web page 🙃 With apps being used more and more, it may be a while before the user actually opens a browser. The flood of error messages may also mean the user stops reading the errors, which lets an actual malicious attack go unnoticed 👀

Some operating systems now come with heuristics that try to recognise captive portals and either log in automatically or show the login page in a separate application. (But some hotspot providers apparently don't want automatic logins, so they reverse-engineered the heuristics to try and fool them 🙄)

It seems like a protocol is missing here. Captive portals shouldn't have to do MITM attacks just to be noticed. A mechanism at the link layer, or an extension to DHCP that tells a connecting device about the login page, may help. Still, that doesn't solve the problem for devices without a web browser, such as voice over IP phones 📞 HTTP response code 511 (defined in [RFC6585]) is another attempt at a partial solution. (It's partial because it can only work at the moment the user uses a browser to connect to a web site and doesn't use HTTPS.)

A practical problem with deploying such a protocol is that many captive portals are very old and never updated. The hotel staff only knows how to reboot the system, and as long as it works, the hotel has no incentive to buy a new one 🏨 As evidence of this: how many of these systems make you get a password, while the ticket shows the price as zero? That's typically because the owner doesn't know how to reconfigure the hotspot, but he does know how to change the price in his cash register 💸

5.8. Break-out 1 - Research 📚

Despite some requests earlier in the workshop, the research break-out did not discuss clean-slate approaches. The real challenge was that the relationship between security research and standardisation needs improvement. Research on linkability isn't well known in the IETF yet. But the other side of the coin needs work too: while doing protocol design, standardisation organisations should point out which specific problems need more research 🔍

The break-out then made a nonexhaustive list of topics that need further research:

  • The interaction of compression and encryption as demonstrated by the CRIME ("Compression Ratio Info-leak Made Easy") SSL/TLS vulnerability [Ristic]
  • A more proactive deprecation of algorithms based on research results
  • Mitigation for return-oriented programming attacks
  • How to better obfuscate so-called "metadata"
  • How to make the existence of traffic and their endpoints stealthy

5.9. Break-out 2 - Clients 💻

Browsers are the first clients everyone thinks of when talking about encrypted connections, authentication, and certificates, but there are lots of others 🌈

Other common "false" alarms for MITM (after captive portals) include expired and misconfigured certificates. This happens a lot on intranets, when the sysadmin hasn't bothered updating a certificate and just tells his handful of users to "click continue" 🙃 The problem is, on one hand, that users may not understand the difference between this case and the same error message they get when connecting to a server outside the company. On the other hand, the incorrect certificate the sysadmin installed isn't easily distinguishable from one used by a MITM. The error message is almost the same, so the user may just click continue again.

One way to get rid of such certificates is if client software no longer offers the option to continue after a certificate error. That requires all major clients (such as browsers) to change their behaviour at the same time. Otherwise, the first one to do it will be considered broken by users, because the others still work 😤 It also requires a period in which the software gives increasingly strong warnings about the cut-off date after which the connection will fail with that certificate.

Yet another source of error messages is self-signed certificates. Those are actually only errors for sites that aren't expected to have them. If a self-signed certificate warning shows up when you connect to Facebook or Google, you're clearly not connected to the real Facebook or Google 🚨 But for a personal web site, it shouldn't cause such scary warnings. There may be ways to improve the explanations in the error message and provide an easy way to verify the certificate (by email, phone, or some other channel) and trust it 🫶

5.10. Break-out 3 - On by Default 🔥

One step toward better security is to require the relevant features (in particular, encryption and authentication) to be implemented in compliant products. The features are labelled as "MUST" in the standard rather than "MAY". This is sometimes referred to as Mandatory To Implement (MTI), and it's the current practice for IETF protocols [RFC3365] 📜

But that may not be enough to counter PM. The features may be there but not used, because only very knowledgeable users or sysadmins turn them on. Or implementations might not actually follow the MTI parts of specifications. Or some security features may be implemented, but interoperability for them doesn't really work. Or, even worse, protocol designers may have only followed the letter of the MTI best practice and not its spirit, so the security features are hard to use or make deployment harder 😩 One can argue that such features should be defined to be on by default ⭐

Going further, one might argue that these features shouldn't even be options, i.e., there should be no way to turn them off. This is sometimes called Mandatory To Use (MTU) 🔒

The questions raised at this session were: for what protocols is on-by-default appropriate, and how can one explain to the developers of such protocols that it's needed? 🤔

Of course, there would be resistance to MTU security from implementers and deployments that practise deep packet inspection (DPI), and perhaps from some governments too. On the other hand, there may also be governments that outlaw protocols without proper encryption 🌍

This break-out concluded that there could be value in trying to document a new Best Current Practice for the IETF that moves from the current MTI position to one where security features are on by default 💖 Some of the workshop participants expressed interest in writing a draft for such a new BCP and pushing it through the IETF consensus process, where it would no doubt be controversial 🍿

5.11. Break-out 4 - Measurement 📊

There was a small break-out on the idea of measurement as a way to encourage or gamify the increased use of security mechanisms 🎮

5.12. Break-out 5 - Opportunistic 🦋

This break-out considered the use of the term "opportunistic" as it applies to cryptographic security. It tried to move the work toward an agreed-upon definition for that term, as it applies to IETF and W3C work 📖

While various terms had been used, with many people talking about opportunistic encryption, that usage was felt to be problematic. It conflicted with the use of the same term in [RFC4322], and it was being used differently in different parts of the community 🙅‍♀️

At the session, it was felt that the term "opportunistic keying" was better. But, as explained above, subsequent list discussion resulted in a move to the term "Opportunistic Security" (OS) 🌸

Aside from terminology, discussion focused on using Diffie-Hellman (D-H) key exchange as the preferred mechanism of OS, with a fallback to cleartext if D-H doesn't succeed, as a counter for passive attacks 🔐

There was also, of course, the desire to be able to easily escalate from countering passive attacks to also handling endpoint authentication, and thereby countering MITM attacks too 👑

Making OS visible to users was again considered undesirable, since users couldn't be expected to tell apart cleartext, OS, and (one-sided or mutual) endpoint authentication 🙈

Finally, it was noted that it may take some effort to work out how middleboxes might affect OS at different layers. OS really isn't suitable as the only mitigation for high-sensitivity sessions, such as financial transactions 💸🫶

5.13. Unofficial Transport/Routing Break-out 🦋

okay so some of the routing and transport Area Directors were lowkey feeling left out 🥺 all the application-layer break-outs got the spotlight, so they ran their own brainstorm about what could be done at the transport and routing layers. These notes are what came out of it 💅

The LEDBAT [RFC6817] protocol was built for a bulk-transfer service that doesn't care about reordering or delay 🧚 Using LEDBAT could give an application these perks:

  • a. Because it's reordering-insensitive, traffic can be sprayed across a bunch of forwarding paths 🌸 As long as those different paths actually exist, it gets way harder to capture and analyze a full interaction 👀
  • b. The application can change paths by giving each packet a different flow. For IPv6, that's done with different IPv6 flow labels ✨ For IPv4, you encapsulate the IP packet in UDP and vary the UDP source port 🎀
  • c. LEDBAT is delay-insensitive, and applications using it would need to be too, so it's possible to obfuscate the application signatures by varying the packet lengths and frequency 🙈
  • d. This can also hide the transport header (for IP in UDP) 🫶
  • e. If the Reverse Path Forwarding (RPF) [RFC3704] check problem can be fixed, maybe the source could be hidden too 👑 but those fixes assume the traffic is within trusted perimeters, so it's not a free pass 💀
  • f. Using LEDBAT is orthogonal to using encryption 🌈 They give different benefits (it's harder to intercept the whole conversation, and you can obfuscate the traffic analysis), and they have different costs for their users (longer latency and new transport protocol usage) ⭐

The idea of encrypting traffic from Customer Edge (CE) to CE as part of an L3VPN or something similar also got discussed 💜 That could allow hiding of addresses, including the source, and headers too. Ron Bonica pointed out that some customers already do encryption (though without hiding the source address), so this isn't really an enhancement. It's an existing mechanism where deployment and use can be encouraged 🍓

Last but not least, people asked whether it'd be useful to have a way of communicating where and what layers are doing encryption on an application's traffic path 🤔 The initial idea of augmenting ICMP has some issues: the application can't see it, and ICMP packets are frequently filtered 🙃 There's also potential work to figure out how to trust the report of encryption. It would be really interesting to find out whether this communication is actually needed, and what the requirements would be 🔥

6. After the Workshop 🎀

holding the workshop right before the IETF totally worked 💖 A bunch of people went to both, and they used the fact that everyone was together at the IETF to keep the discussions going 🫶

IETF working groups meeting in London took the workshop recommendations into account ✨ It was even the first item in the IETF chair Jari Arkko's report about the meeting:

Strengthening the security and privacy of the Internet continued to draw a lot of attention. The STRINT workshop organised by the IAB and W3C just before the IETF attracted 100 participants and over 60 papers. Even more people would have joined us, but there was no space. During the IETF meeting, we continued discussing the topic at various working groups. A while ago we created the first working group specifically aimed at addressing some of the issues surrounding pervasive monitoring. The Using TLS for Applications (UTA) working group had its first meeting in London. But many other working groups also address these issues in their own work. The TCPM working group discussed a proposal to add opportunistic keying mechanisms directly onto the TCP protocol. And the DNSE BOF considered the possibility of adding confidentiality support to DNS queries. Finally, there is an ongoing effort to review old specifications to search for areas that might benefit from taking privacy and data minimisation better into account. [Arkko1]

Two papers written for the workshop but not finished in time are worth a mention too 📚 One is by the same Jari Arkko, titled "Privacy and Networking Functions" [Arkko2]. The other is by Johan Pouwelse, "The Shadow Internet: liberation from Surveillance, Censorship and Servers" [Pouwelse] 🧚

7. Security Considerations 🔐

okay this one is short but it's SO important 😭 This document is all about security and privacy. Literally the whole vibe, no cap 👑🔥

8. Informative References 📚

these are all the sources this doc pulls from, with every detail kept so nobody gets lost 🫶

Appendix A. Logistics ✨

okay so the workshop was organised by the STREWS project 🌸 (<https://www.strews.eu/>), which is a research project funded under the European Union's 7th Framework Programme (<http://cordis.europa.eu/fp7/ict/>). it was the first of two workshops in their work plan 💅 The organisers were supported by the IAB and W3C, and for the local organisation, by Telefonica Digital (<http://blog.digital.telefonica.com/>) 🫶

one of the suggestions in the STREWS project description was to attach the first workshop to an IETF meeting 🦋 The best opportunity was IETF 89 in London, which began on Sunday 2 March 2014. see <https://www.ietf.org/meeting/89/> for more info! Telefonica Digital offered meeting rooms at its offices in central London for the preceding Friday and Saturday, just minutes away from the IETF's location 🎀

the room held 100 people, which was thought to be sufficient. there turned out to be more interest than expected and they could have filled a bigger room, but 100 people is probably an upper limit for good discussions anyway 🙈

apart from the usual equipment in the room (projector, white boards, microphones, coffee ☕), they also set up some extra communication channels 🧚

  • A mailing list where participants could discuss the agenda and the published papers about three weeks in advance of the workshop itself.
  • Publicly advertised streaming audio (one-way only). At some point, no less than 165 people were listening 😭
  • An IRC channel for live minute-taking, passing links and other information, and helping remote participants to follow the proceedings.
  • An Etherpad, where the authors of papers could provide an abstract of their submissions, to help participants who could not read all 66 papers in full in advance of the workshop. The abstracts were also used on the workshop's web site: <https://www.w3.org/2014/strint/>.
  • A Twitter hashtag (#strint). Four weeks after the workshop, there were still a few new messages about events related to workshop topics; see <https://twitter.com/search?q=%23strint>.

Appendix B. Agenda 🗓️

this was the final agenda of the workshop, as determined by the TPC and participants on the mailing list prior to the workshop. the included links go to the slides the moderators used to introduce each discussion topic, and to the minutes 💖

B.1. Friday 28 February

Minutes: <http://www.w3.org/2014/02/28-strint-minutes.html>

Workshop starts, welcome, logistics, opening/overview Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s0-welcome.pdf>

  • Goal is to plan how we respond to PM threats
  • Specific questions to be discussed in sessions
  • Outcomes are actions for IETF, W3C, IRTF, etc.

I. Threats - What problem are we trying to solve? (Presenter: Richard Barnes; Moderator: Cullen Jennings) Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s1-threat.pdf>

  • What attacks have been described? (Attack taxonomy)
  • What should we assume the attackers' capabilities are?
  • When is it really "pervasive monitoring" and when is it not?
  • Scoping - what's in and what's out? (for IETF/W3C)

II. COMSEC 1 - How can we increase usage of current COMSEC tools? (Presenter: Hannes Tschofenig; Moderator: Leif Johansson) Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s2-comsec.pdf>

  • Whirlwind catalog of current tools
  • Why aren't people using them? In what situations are / aren't they used?
  • Securing AAA and management protocols - why not?
  • How can we (IETF/W3C/community) encourage more/better use?

III. Policy - What policy/legal/other issues need to be taken into account? (Presenter: Christine Runnegar; Moderator: Rigo Wenning) Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s3-policy.pdf>

  • What non-technical activities do we need to be aware of?
  • How might such non-technical activities impact on IETF/W3C?
  • How might IETF/W3C activities impact those non-technical activities?

Saturday plan, open mic, wrap-up of the day

B.2. Saturday 1 March

Minutes: <http://www.w3.org/2014/03/01-strint-minutes.html>

IV. COMSEC 2 - What improvements to COMSEC tools are needed? (Presenter: Mark Nottingham; Moderator: Steve Bellovin) Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s4-opportunistic.pdf>

  • Opportunistic encryption - what is it and where it might apply
  • Mitigations aiming to block PM vs. detect PM - when to try which?

V. Metadata - How can we reduce the metadata that protocols expose? (Presenters: Alfredo Pironti, Ted Hardie; Moderator: Alissa Cooper)

Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s5-1metadata-pironti.pdf> <https://down.dsg.cs.tcd.ie/strint-slides/s5-2metadata-hardie.pdf> <https://down.dsg.cs.tcd.ie/strint-slides/s5-3metadata-cooper.pdf>

  • Metadata, fingerprinting, minimisation
  • What's out there?
  • How can we do better?

VI. Deployment - How can we address PM in deployment / operations? (Presenter: Eliot Lear; Moderator: Barry Leiba) Slides: <https://down.dsg.cs.tcd.ie/strint-slides/s6-deploy.pdf>

  • "Mega"-commercial services (clouds, large-scale email and Online Social Networks, SIP, WebRTC)
  • Target dispersal - good goal or wishful thinking?
  • Middleboxes: when a help and when a hindrance?

VII. Break-out Sessions (x 3) / Bar-Camp style (Hannes Tschofenig)

  • Content to be defined during meeting, as topics come up
  • Sum up at the end to gather conclusions for report

Break-outs:

  1. Research Questions (Moderator: Kenny Paterson)
    • Do we need more/different crypto tools?
    • How can applications make better use of COMSEC tools?
    • What research topics could be handled in IRTF?
    • What other research would help?
  2. Clients
  3. On by default
  4. Measurement
  5. Opportunistic

VIII. Break-out Reports, Open Mic & Conclusions - What are we going to do to address PM? Slides: <https://www.w3.org/2014/strint/slides/summary.pdf>

  • Gather conclusions / recommendations / goals from earlier sessions

Appendix C. Workshop Chairs and Program Committee 🎀

the workshop chairs were three: Stephen Farrell (TCD) and Rigo Wenning (W3C) from the STREWS project, and Hannes Tschofenig (ARM) from the STREWS Interest Group 👑

the Technical Programme Committee (TPC) was charged with evaluating the submitted papers. it was made up of the members of the STREWS project, the members of the STREWS Interest Group, plus invited experts: Bernard Aboba (Microsoft), Dan Appelquist (Telefonica & W3C TAG), Richard Barnes (Mozilla), Bert Bos (W3C), Lieven Desmet (KU Leuven), Karen O'Donoghue (ISOC), Russ Housley (Vigil Security), Martin Johns (SAP), Ben Laurie (Google), Eliot Lear (Cisco), Kenny Paterson (Royal Holloway), Eric Rescorla (RTFM), Wendy Seltzer (W3C), Dave Thaler (Microsoft), and Sean Turner (IECA) 🌈

Appendix D. Participants 🦋

the participants to the workshop were:

  • Bernard Aboba (Microsoft Corporation)
  • Thijs Alkemade (Adium)
  • Daniel Appelquist (Telefonica Digital)
  • Jari Arkko (Ericsson)
  • Alia Atlas (Juniper Networks)
  • Emmanuel Baccelli (INRIA)
  • Mary Barnes
  • Richard Barnes (Mozilla)
  • Steve Bellovin (Columbia University)
  • Andrea Bittau (Stanford University)
  • Marc Blanchet (Viagenie)
  • Carsten Bormann (Uni Bremen TZI)
  • Bert Bos (W3C)
  • Ian Brown (Oxford University)
  • Stewart Bryant (Cisco Systems)
  • Randy Bush (IIJ / Dragon Research Labs)
  • Kelsey Cairns (Washington State University)
  • Stuart Cheshire (Apple)
  • Vincent Cheval (University of Birmingham)
  • Benoit Claise (Cisco)
  • Alissa Cooper (Cisco)
  • Dave Crocker (Brandenburg InternetWorking)
  • Leslie Daigle (Internet Society)
  • George Danezis (University College London)
  • Spencer Dawkins (Huawei)
  • Mark Donnelly (Painless Security)
  • Nick Doty (W3C)
  • Dan Druta (AT&T)
  • Peter Eckersley (Electronic Frontier Foundation)
  • Lars Eggert (NetApp)
  • Kai Engert (Red Hat)
  • Monika Ermert
  • Stephen Farrell (Trinity College Dublin)
  • Barbara Fraser (Cisco)
  • Virginie Galindo (gemalto)
  • Stefanie Gerdes (Uni Bremen TZI)
  • Daniel Kahn Gillmor (ACLU)
  • Wendy M. Grossman
  • Christian Grothoff (The GNUnet Project)
  • Oliver Hahm (INRIA)
  • Joseph Lorenzo Hall (Center for Democracy & Technology)
  • Phillip Hallam-Baker
  • Harry Halpin (W3C/MIT and IRI)
  • Ted Hardie (Google)
  • Joe Hildebrand (Cisco Systems)
  • Russ Housley (Vigil Security, LLC)
  • Cullen Jennings (CISCO)
  • Leif Johansson (SUNET)
  • Harold Johnson (Irdeto)
  • Alan Johnston (Avaya)
  • L. Aaron Kaplan (CERT.at)
  • Steve Kent (BBN Technologies)
  • Achim Klabunde (European Data Protection Supervisor)
  • Hans Kuhn (NOC)
  • Christian de Larrinaga
  • Ben Laurie (Google)
  • Eliot Lear (Cisco Ssytems)
  • Barry Leiba (Huawei Technologies)
  • Sebastian Lekies (SAP AG)
  • Orit Levin (Microsoft Corporation)
  • Carlo Von LynX (#youbroketheinternet)
  • Xavier Marjou (Orange)
  • Larry Masinter (Adobe)
  • John Mattsson (Ericsson)
  • Patrick McManus (Mozilla)
  • Doug Montgomery (NIST)
  • Kathleen Moriarty (EMC)
  • Alec Muffett (Facebook)
  • Suhas Nandakumar (Cisco Systems)
  • Linh Nguyen (ERCIM/W3C)
  • Linus Nordberg (NORDUnet)
  • Mark Nottingham
  • Karen O'Donoghue (Internet Society)
  • Piers O'Hanlon (Oxford Internet Institute)
  • Kenny Paterson (Royal Holloway, University of London)
  • Jon Peterson (Neustar)
  • Joshua Phillips (University of Birmingham)
  • Alfredo Pironti (INRIA)
  • Dana Polatin-Reuben (University of Oxford)
  • Prof. Johan Pouwelse (Delft University of Technology)
  • Max Pritikin (Cisco)
  • Eric Rescorla (Mozilla)
  • Pete Resnick (Qualcomm Technologies, Inc.)
  • Tom Ristenpart (University of Wisconsin)
  • Andrei Robachevsky (Internet Society)
  • David Rogers (Copper Horse)
  • Scott Rose (NIST)
  • Christine Runnegar (Internet Society)
  • Philippe De Ryck (DistriNet - KU Leuven)
  • Peter Saint-Andre (&yet)
  • Runa A. Sandvik (Center for Democracy and Technology)
  • Jakob Schlyter
  • Dr. Jan Seedorf (NEC Laboratories Europe)
  • Wendy Seltzer (W3C)
  • Melinda Shore (No Mountain Software)
  • Dave Thaler (Microsoft)
  • Brian Trammell (ETH Zurich)
  • Hannes Tschofenig (ARM Limited)
  • Sean Turner (IECA, Inc.)
  • Matthias Waehlisch (Freie Universitaet Berlin)
  • Greg Walton (Oxford University)
  • Rigo Wenning (W3C)
  • Tara Whalen (Apple Inc.)
  • Greg Wood (Internet Society)
  • Jiangshan Yu (University of Birmingham)
  • Aaron Zauner
  • Dacheng Zhang (Huawei)
  • Phil Zimmermann (Silent Circle LLC)
  • Juan-Carlos Zuniga (InterDigital)

Authors' Addresses 💌

Okay bestie, here are the amazing humans who wrote this whole thing 🫶 Their names, emails, and websites are copied exactly, so you can reach out if you need to 💅

   Stephen Farrell
   Trinity College, Dublin
   Email: stephen.farrell@cs.tcd.ie
   URI:   https://www.cs.tcd.ie/Stephen.Farrell/


   Rigo Wenning
   World Wide Web Consortium
   2004, route des Lucioles
   B.P. 93
   Sophia-Antipolis  06902
   France
   Email: rigo@w3.org
   URI:   http://www.w3.org/People/Rigo/


   Bert Bos
   World Wide Web Consortium
   2004, route des Lucioles
   B.P. 93
   Sophia-Antipolis  06902
   France
   Email: bert@w3.org


   Marc Blanchet
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada
   Email: Marc.Blanchet@viagenie.ca
   URI:   http://viagenie.ca


   Hannes Tschofenig
   ARM Ltd.
   110 Fulbourn Rd
   Cambridge  CB1 9NJ
   Great Britain
   Email: Hannes.tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at
📦 where this page comes from