Future Scenarios Breakout discussions as AIMS/KISMET 2020 February 11, 2020 At our first workshop in December 2019, we spent a majority of the time hearing about various datasets that might be useful as a starting point to explore ways to improve the security of the Internet. In this workshop, we are proposing a different exercise as part of the agenda: we are posing some possible scenarios for the future of the Internet, and we will ask the attendees to break up into smaller groups to discuss these scenarios. Each of these scenarios describes a possible future for the Internet. Some scenarios relate directly to trends that might change the security of the Internet, others relate to more general trends about the future shape of the Internet itself, and we want to ask how these trends might lead to a more secure future. Of course, these scenarios might not come to pass. The groups should feel free to pose alternative futures that might arise instead of the one described here. What sort of data or analysis might allow us to predict the probability of one or another outcome? But we also want the groups to consider the question of “what if”. If these outcomes do happen, what would be the implications for the security, stability and governance of the Internet? Some of the ideas behind these future scenarios are young ideas—not yet well-enough formed to be called “good” ideas. We ask you to think positively. How might these ideas be shaped or modified to have the best chance of success? For all of these discussions, a key high-level question is whether there is data of any sort that might shed light on the scenario: the probability of its happening and the implications if it did. 1
The rise of the app With the advent of mobile devices, more and more of the user experience is not by means of a web browser, but instead by the use of an “app”, which directly embodies the desired application behavior using code that runs on the end device. Apps are also being written for laptop operating systems as well as mobile systems, so even on the traditional computer the center of the user experience is shifting from the browser to app code running on the end node. What are the implications of this trend for the security of the Internet, and for the app itself? This trend represents a shift in power and control. The provider of the browser could shape the user experience, monitor what the user was doing, protect the user from some forms of abuse, and so on. The proposal for DoH moved the control over which recursive resolver was used for DNS lookups from the OS to the browser. Now, the move from the browser to the app again shifts power and control. There is a generality in the browser that need not be duplicated in code that is specific to an app. The app designer can use service elements in the OS that support web functionality, but can pick and choose among these3 to tailor the design of the app. For example, the app can control how it resolves names into addresses. It can invoke the OS service, embed a DNS protocol and resolver address in its code, or (in some cases) avoid using the DNS all together. For apps that primarily need to connect to a centralized component, the mechanism by which the address of that component is found need not depend on the DNS, but could be a custom mechanism. In this app context, what is the future of advertising? Will the app code on the end node resolve URLs to fetch ads, or will they come via an app component in the cloud? To the extent that certificates are required to validate the other parties in the communication, how might these be managed? Today, the list of trusted root certificates is stored in the browser or the OS. Might trust roots be provided as part of the app? What would this trend imply? How might attempts to hijack routes or impersonate remote sites manifest in this context. What sorts of applications are not amenable to being coded as end-point code rather than through a browser? Extra credit Imagine that there is a push to develop applications that are more decentralized in character (think about the original shape of email), as opposed to the highly centralized applications of today such as Facebook. What issues will arise as a part of making distributed applications more secure? 2
The regionalization of the Internet There are forces at several levels that are pushing toward a more regionalized Internet. Content is being specialized for different parts of the world. Different applications are used in different parts of the world, Some countries are explicitly pushing for the Internet experience in their country to be localized to that country. At a topological level, more and more of the services that a user invokes today are provided by service points that are directly connected to the access network of that user. High volume services such as Netflix and Youtube directly connect to access providers to improve delivery and reduce costs; other services utilize service points directly connected to access networks to improve resilience as well as performance. Less and less of the user traffic is crossing multiple ASs on its way to its destination. There are proposals to explicitly move in this direction to improve the resistance of the Internet to events such as DDoS attacks. For example, the Dutch government is proposing to work with its domestic ISPs to ensure that all critical services for Dutch citizens are directly connected to those domestic ISPs. They do not intend to sever the connections to the rest of the Internet, but they could be rate-limited during a DDoS event to prevent Dutch services from being overwhelmed. Their view is that Holland is small enough that it will be a challenge for an attacker to build a large enough botnet inside Holland to launch an attack internally. Imagine that the Internet evolves in this direction. What does that imply for the core services of the Internet, and their current security vulnerabilities? • Does this trend reduce the need to worry about BGP hijacking? • Are there approached to managing DNS queries that can better protect such a region? • What about management of the CA system within a region? • What would it mean in practice to manage DDoS attacks in this context? • Could a region as large as the US be protected in this way? • List important classes of apps that cannot be regionalized in this way. Extra credit It is not clear that the region of trust that is created by the direct connection of service points to access networks needs to have the same scope as a region of trust that manages DNS lookups, the CA system, and so on. Are their more general concepts of regional protection that could improve the security of the Internet and its users in that region? Setting aside the extreme of countries that want to quarantine their users to an experience restricted to that country, as content and applications become more localized to different regions, how can that trend be exploited to make the experience within regions more secure and trustworthy. 3
Beyond blacklist blocking It is well-documented that there are certain DNS registrars and TLDs that are highly involved in the registration of abusive DNS names. What if, for those actors that get above a certain threshold of support for abusive registrations over some period of time, a group of operators of recursive resolvers switch from a blacklist model to a whitelist model, where all names are blocked by default? The group could construct the whitelist independent of the domain provider, or the group could require that the provider undertake a somewhat onerous request process as a part of getting a single domain name white-listed. • Perhaps the group could requite that the registrar/TLD reveal more information about the registrant than ICANN requires in order to get the name white-listed. There is an analog here to credit card processing. Merchants must code all card transactions with the type of transaction, and if the trans- action is miscoded, the credit card network may throw out the merchant (and bank) . So merchants (mostly) report this data accurately. By making the rules clear, the group can impose some discipline on reporting by the registrar/registry. • Could domain operators seek legal relief from such a discipline? • Perhaps the group can require that the registrar/TLD pay a fee to whitelist a name. Would this constitute criminal extortion by the group of operators? • In the CA space, there is a somewhat similar organization, the CA/Browser Forum, 1 which vets CAs and determines that some CAs are not trustworthy. It is voluntary, but since all the major browser providers participate, it has a lot of clout. What can be learned from the experience in that space? Alternative approach: As an alternative to whitelisting, operators of resolvers might move to more aggressive blacklisting to discipline domains and registrars that seem to encourage abuse. • Again, could domain operators seek legal relief from such a discipline? • In order to focus attention on the abusive domains, would it be effective to design some sort of mechanism that would allow resolver operators to share (and perhaps make public) what domains they are blocking? • More aggressive blocking might cause collateral harm, as innocent urls are blocked. Can research estimate the magnitude of this potential harm, perhaps by looking at logs of queries to recursive resolvers? Could decisions to block at a regional level better mitigate harms? 1 https://cabforum.org/ 4
Recommend
More recommend
