Internet-Draft IETF Policy Interactions July 2023
Nottingham & Cooper Expires 8 January 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-cooper-policy-interactions-latest
Published:
Intended Status:
Informational
Expires:
Authors:
M. Nottingham
Cloudflare
A. Cooper
Cisco

IETF Policy Interactions

Abstract

This document captures a list of interactions between IETF efforts and policy efforts.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://coopdanger.github.io/draft-ietf-policy-interactions/draft-cooper-policy-interactions.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cooper-policy-interactions/.

Source for this draft and an issue tracker can be found at https://github.com/coopdanger/draft-ietf-policy-interactions.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 8 January 2024.

Table of Contents

1. 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.

2. Policy Interactions

2.1. 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.

[RFC1984] 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.

[RFC2804] articulates why the IESG and IAB believed that it was not appropriate to accommodate wiretapping requirements from law enforcement, circa 2000.

[RFC3365] set a requirement for IETF standard protocols to use 'appropriate strong security mechanisms', including encryption. It was published as Best Current Practice in 2002.

[RFC7258] 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 [RFC7258] includes opportunistic encryption [RFC7435] [RFC8110] [RFC8164], data minimization [RFC7816] [RFC9156], improvements to the encryption ecosystem such as [ACME], and discussion of mandatory encryption in [HTTP2], [TLS13], and [QUIC].

2.2. DNS-over-HTTPS (DOH)

[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

2.3. TLS Encrypted Client Hello (ECH)

[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

2.4. 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 [RFC3261] and the rest of the SIP document suite.

2.5. 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 [RFC5222] and the rest of the document suite.

2.6. Caller identity authentication

Secure Telephone Identity Revisited (STIR) and the related SHAKEN initiative are designed to combat caller ID spoofing that uses VoIP.

See [RFC8224], [RFC8225], [RFC8226], and [RFC8588].

Regulatory mandates to use STIR exist in the US, Canada, and France thus far.

2.7. 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.

2.8. 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.

2.9. 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.

2.10. 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).

2.11. P2P congestion control

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

2.12. 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.

3. Security Considerations

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

4. IANA Considerations

This document has no IANA actions.

5. Informative References

[ACME]
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <https://www.rfc-editor.org/rfc/rfc8555>.
[DOH]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <https://www.rfc-editor.org/rfc/rfc8484>.
[ECH]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-16>.
[HTTP2]
Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, , <https://www.rfc-editor.org/rfc/rfc7540>.
[QUIC]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.
[RFC1984]
IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, , <https://www.rfc-editor.org/rfc/rfc1984>.
[RFC2804]
IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, DOI 10.17487/RFC2804, , <https://www.rfc-editor.org/rfc/rfc2804>.
[RFC3261]
Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, , <https://www.rfc-editor.org/rfc/rfc3261>.
[RFC3365]
Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, , <https://www.rfc-editor.org/rfc/rfc3365>.
[RFC5222]
Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, , <https://www.rfc-editor.org/rfc/rfc5222>.
[RFC5594]
Peterson, J. and A. Cooper, "Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008", RFC 5594, DOI 10.17487/RFC5594, , <https://www.rfc-editor.org/rfc/rfc5594>.
[RFC7258]
Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, , <https://www.rfc-editor.org/rfc/rfc7258>.
[RFC7435]
Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, , <https://www.rfc-editor.org/rfc/rfc7435>.
[RFC7567]
Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, , <https://www.rfc-editor.org/rfc/rfc7567>.
[RFC7713]
Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, , <https://www.rfc-editor.org/rfc/rfc7713>.
[RFC7816]
Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, , <https://www.rfc-editor.org/rfc/rfc7816>.
[RFC8110]
Harkins, D., Ed. and W. Kumari, Ed., "Opportunistic Wireless Encryption", RFC 8110, DOI 10.17487/RFC8110, , <https://www.rfc-editor.org/rfc/rfc8110>.
[RFC8164]
Nottingham, M. and M. Thomson, "Opportunistic Security for HTTP/2", RFC 8164, DOI 10.17487/RFC8164, , <https://www.rfc-editor.org/rfc/rfc8164>.
[RFC8224]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, , <https://www.rfc-editor.org/rfc/rfc8224>.
[RFC8225]
Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, , <https://www.rfc-editor.org/rfc/rfc8225>.
[RFC8226]
Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, , <https://www.rfc-editor.org/rfc/rfc8226>.
[RFC8588]
Wendt, C. and M. Barnes, "Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)", RFC 8588, DOI 10.17487/RFC8588, , <https://www.rfc-editor.org/rfc/rfc8588>.
[RFC9156]
Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, , <https://www.rfc-editor.org/rfc/rfc9156>.
[TLS13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.

Authors' Addresses

Mark Nottingham
Cloudflare
Alissa Cooper
Cisco