]> Cloudflare

mnot@mnot.net

Cisco

alcoop@cisco.com

This document captures a list of interactions between IETF efforts and policy efforts. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction This document captures a list of interactions between IETF standards-related efforts and external policy efforts (e.g., regulation or legislation) around the world, past or present. The objective of this document is merely to catalogue these interactions in a single location. Comments and additional suggestions of policy interactions not listed here should be submitted via the issue tracker at https://github.com/coopdanger/draft-ietf-policy-interactions.

Policy Interactions

Encryption and Access to Communications THE IETF has a history of publishing documents that respond to policy developments surrounding the use of encryption, and more generally regarding access to communications. stated the IESG and IAB's position regarding legal constraints on encryption in 1996, with a focus on the effects on the Internet. The publication of the document was prompted in part by the controversy surrounding the US government's promotion of the Clipper Chip. The document was elevated to Best Current Practice (which requires IETF-wide consensus) in 2015. articulates why the IESG and IAB believed that it was not appropriate to accommodate wiretapping requirements from law enforcement, circa 2000. set a requirement for IETF standard protocols to use 'appropriate strong security mechanisms', including encryption. It was published as Best Current Practice in 2002. documents IETF consensus that pervasive monitoring is an attack, and thus should be mitigated in IETF protocols (often, using encryption). It was a response to the Snowden revelations, and followed the Workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT) https://www.w3.org/2014/strint/, held jointly by the W3C and IAB. Follow-on work to implement includes opportunistic encryption , data minimization , improvements to the encryption ecosystem such as , and discussion of mandatory encryption in , , and .

DNS-over-HTTPS (DOH) was a technical response to pervasive monitoring attacks on DNS. Some related news reporting: * Proposal to regulate in Russia * GCHQ sends 'warning' to Google and Mozilla over DoH * Congressional scrutiny of DoH

TLS Encrypted Client Hello (ECH) is a work-in-progress effort to respond to pervasive monitoring attacks on TLS SNI, which exposes the hostname =being connected to, even when several hostnames are served by the same IP address. Some related news reporting: * Proposal to regulate in Russia * ESNI blocked in China

Voice over IP The development of the Session Initiation Protocol (SIP) in the early 2000s had involvement from regulators and their proxies. There is a very significant amount of PSTN interop built into SIP. See and the rest of the SIP document suite.

Emergency services The Emergency Context Resolution with Internet Technologies (ECRIT) working group, which began in the starting mid-2000s, had extensive involvement from people working for/with Public Safety Answering Points (PSAPs) as well as some input from telecom regulators such as the US Federal Communications Commission (FCC). See and the rest of the document suite.

Caller identity authentication Secure Telephone Identity Revisited (STIR) and the related SHAKEN initiative are designed to combat caller ID spoofing that uses VoIP. See , , , and . Regulatory mandates to use STIR exist in the US, Canada, and France thus far.

Messaging interoperability The More Instant Messaging Interoperability (MIMI) working group is chartered to work on interoperability for encrypted messaging. This work was instigated based on requirements in the EU Digital Markets Act (DMA). Several of the key participants have met with European Commission (EC) staff and participated in an EC workshop on the topic. The area director and co-chairs are staying in touch with the EC staff focused on messaging interoperability.

TV whitespaces database protocol The Protocol to Access Whitespaces (PAWS) working group was created based on requirements received from the FCC after they allocated TV whitespaces spectrum for unlicensed use.

Broadband measurement The Large-Scale Measurement of Broadband Performance (LMAP) working group was created as a result of disparate efforts by Ofcom in the UK, the FCC, and the Body of European Regulators of Electronic Communications (BEREC), who were all running their own jurisdiction-specific broadband speed measurement efforts (several of them using a vendor which had its own proprietary measurement protocol). There were regulator participants involved in the protocol development effort.

Incident response There has been long-term involvement (including people in area director roles) from those involved with various CERTs and national cybersecurity authorities in several of the IETF's working groups focused on incident response and exchange of incident/vulnerability information: Managed Incident Lightweight Exchange (MILE), Security Automation and Continuous Monitoring (SACM), and DDoS Open Threat Signaling (DOTS).

P2P congestion control In 2008, the IETF hosted a workshop that was spurred by an FCC action regarding P2P traffic throttling. See . Related challenges associated with multiplexing flows with different characteristics were addressed in the Active Queue Management working group (see, e.g., ) and in the Congestion Exposure working group (see, e.g., ).

Internet Architecture Board (IAB) In addition to the IAB's coordination with the Internet Society on policy matters, the IAB also frequently contributes to policy and regulatory proceedings around the world. Some recent examples:

• 2022: FTC commercial surveillance proceeding, European Commission eIDAS comments
• 2018: NTIA comments on national privacy priorities, comments on Australian exceptional access bill

IAB workshops also frequently include regulatory or policy perspectives, for example, the unwanted traffic workshop and the CARIS workshop.

Security Considerations A number of the policy interactions above relate to security, encryption, and law enforcement access.

IANA Considerations This document has no IANA actions.

Informative References Internet Architecture Board Internet Engineering Steering Group The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Internet Architecture Board Internet Engineering Steering Group This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. This memo provides information for the Internet community. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet. This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media. This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks. This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. 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. RTFM, Inc. Fastly Cloudflare Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK] The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. This memo provides information for the Internet community. This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309. This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.