Ericsson

Valitie 1B Kauniainen Finland jari.arkko@piuha.net

Internet-Draft Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This document recommends that this is no longer alone sufficient to cater for the security and privacy issues seen on the Internet today. For instance, it is often also necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. While such protection is difficult, there are some measures that can be taken. It is important to consider the role of data passed to various parties – including the primary protocol participants – and balance the information given to them considering their roles and possible compromise of the information.

Communications security has been at the center of many security improvements on the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This has been exemplified in many aspects of IETF efforts, in the threat models , concerns about surveillance , IAB statements , and the introduction of encryption in many protocols , , . This has been very successful. Advances in protecting most of our communications with strong cryptographic has resulted in much improved security. Work on these advances continues to be a key part of IETF’s security effort. This document recommends that further action is needed, however. For instance, the possibility that endpoints are compromised, malicious, or have interests that do not align with the interests of users. Given the advances in communication seceurity, adversaries have had to increase their pressure against new avenues of attack. New adversaries and risks have also arisen, e.g., due to increasing amount of information stored in various Internet services. While such protection is difficult, there are some measures that can be taken. This document focuses on the specific question of data passed to various parties – including the primary protocol participants. What information given to any other party needs to depend on the role of that party, with the possibility of a compromised access to the information kept in mind. This consideration is important particularly when designing new technology or planning new deployments. Careful control of information is also necessary from the perspective of technology evolution. For instance, allowing a participant to unnecessarily collect or receive information may lead to a similar effect as described in for protocols: over time, unnecessary information will get used with all the associated downsides, regardless of what deployment expectations there were during protocol design. This may also lead to ossification, as systems start to expect they have access to the information.

The Principle of Least Privilege is applicable:

In this context, it is recommended that the protocol participants minimize the information they share. I.e., they should provide only the information to each other that is necessary for the function that is expected to be performed by the other party. This recommendation is of course very similar to the current approach to communications security. As with communication security, we try to avoid providing too much information as it may be misused or leak through attacks. The same principle applies not just to routers and potential attackers on path, but also many other services in the Internet, including servers that provide some function. Of course, participants may provide more information to each after careful consideration, e.g., information provided in exchange of some benefit, or to parties that are trusted by the participant.

Information disclosure may relate to different types of protocol exchanges: The interaction of an endpoint with the network, e.g., information they provide in any network attachment process or the wire images of the packets sent via the network. The interaction of an endpoint with intermediaries, in the meaning discussed by Thomson . The interaction of an endpoint with a service, such as a website or social networking function. End-to-end interactions between users, represented by applications running on their computers. It is also important to observe that information disclosure can appear in several ways. It can be explicitly carried information, e.g., a data item in a message sent to a protocol participant. But it can also be indirectly inferred information, such as message arrival times or patterns in the traffic flow. Information may also be obtained from fingerprinting the protocol participants, in an effort to identify unique endpoints or users. Finally, information gathered from a collaboration among several parties, e.g., websites and social media systems collaborating to identify visiting users .

Even with careful exposure of information, compromises may occur. It is important to build defenses to protect information, even when some component in a system is or becomes compromised. This may involve designs where no single party has all information such as with Oblivious DNS, cryptographic designs where a service such as with the recent IETF PPM effort, service side encryption of data at rest, confidential computing, and other mechanisms. Protocols can ensure that forward secrecy is provided, so that the damage resulting from a compromise of keying material has limited impact. On the client side, the client may trust that another party handles information appropriately, but take steps to ensure or verify that this is the case. For instance, as discussed above, the client can encrypt a message only to the actual final recipient, even if the server holds our message before it is delivered. A corollary of the recommendation is that information should not be disclosed, stored, or routed in cleartext through services that do not need to have that information for the function they perform. For instance, a transport connection between two components of a system is not an end-to-end connection even if it encompasses all the protocol layers up to the application layer. It is not end-to-end, if the information or control function it carries extends beyond those components. For instance, just because an e-mail server can read the contents of an e-mail message do not make it a legitimate recipient of the e-mail. The general topic of ensuring that protocol mechanisms stays evolvable and workable is covered in . But the associated methods for reducing fingerprinting possibilities probably deserve further study. discusses one aspect of this.

Trends in attacks have been discussed at length in, for instance, in , , , and others. Hardie discusses path signals, i.e., messages to or from on-path elements to endpoints. In the past, path signals were often implicit, e.g., network nodes interpreting in a particular way transport protocol headers originally intended for end-to-end consumption. The document recommends a principle that implicit signals should be avoided and that explicit signals be used instead, and only when the signal’s originator intends that it be used by the network elements on the path. Arkko, Kuhlewind, Pauly, and Hardie discuss the same topic, and extend the RFC 8558 principles with recommendations to ensure minimum set of parties, minimum information, and consent. Thomson discusses the role intermediaries in the Internet architecture, at different layers of the stack. For instance, a router is an intermediary, some parts of DNS infrastructure can be intermediaries, messaging gateways are intermediaries. Thomson discusses when intermediaries are or are not an appropriate tool, and presents a number of principles relating to the use of intermediaries, e.g., deliberate selection of protocol participants or limiting the capabilities or information exposure related to the intermediaries. Trammel and Kühlewind discuss the concept of a “wire image” of a protocol. This is an abstraction of the information available to an on-path non-participant in a networking protocol. It relates to the topic of non-participants interpreting information that is available to them in the “wire image” (or associated timing and other indirect information). The issues are largely the same even for participants. Even proper protocol participants may start to use information available to them, regardless of whether it was intended to that participant or simply relayed through them.

The author would like to thank the members of the IAB, and the participants of IETF SAAG WG, Model-T IAB program, and the 2019 IAB DEDR workshop that all discussed some aspects of these issues. The author would like to acknowledge the significant contributions of Martin Thomson, Stephen Farrell, Mark McFadden, John Mattsson, Chris Wood, Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton, Mirja Kuehlewind, Tommy Pauly, Jaime Jiménez and Christian Huitema in discussions around this general problem area.

All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used. The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Trinity College Dublin We argue that an expanded threat model is needed for Internet protocol development as protocol endpoints can no longer be considered to be generally trustworthy for any general definition of "trustworthy." Ericsson Trinity College Dublin Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This memo suggests that the existing RFC 3552 threat model, while important and still valid, is no longer alone sufficient to cater for the pressing security and privacy issues seen on the Internet today. For instance, it is often also necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. While such protection is difficult, there are some measures that can be taken and we argue that investigation of these issues is warranted. It is particularly important to ensure that as we continue to develop Internet technology, non-communications security related threats, and privacy issues, are properly understood. Last Press Label RFC 3552 introduces a threat model that does not include endpoint security. In the fifteen years since RFC 3552 security issues and cyber attacks have increased, especially on the endpoint. This document proposes a new approach to Internet cyber security protocol development that focuses on the user of the Internet, namely those who use the endpoint and are the most vulnerable to attacks. Ericsson Cisco Apple Ericsson This document discusses principles for designing mechanisms that use or provide path signals, and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements, and points out that visible information will be used whether it is intended as a signal or not. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties and minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path. Mozilla This document proposes a set of principles for designing protocols with rules for intermediaries. The goal of these principles is to limit the ways in which intermediaries can produce undesirable effects and to protect the useful functions that intermediaries legitimately provide. Mozilla Apple The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. University of Waterloo HK University of Science and Technology Apple, Inc. The IETF is well on its way to protecting connection metadata with protocols such as DNS-over-TLS and DNS-over-HTTPS, and work-in- progress towards encrypting the TLS SNI. However, more work is needed to protect traffic metadata, especially in the context of web traffic. In this document, we survey Website Fingerprinting attacks, which are a class of attacks that use machine learning techniques to attack web privacy, and highlight metadata leaks used by said attacks. We also survey proposed mitigations for such leakage and discuss their applicability to IETF protocols such as TLS, QUIC, and HTTP. We endeavor to show that Website Fingerprinting attacks are a serious problem that affect all Internet users, and we pose open problems and directions for future research in this area.