Internet DRAFT - draft-cooper-policy-interactions
draft-cooper-policy-interactions
Network Working Group M. Nottingham
Internet-Draft Cloudflare
Intended status: Informational A. Cooper
Expires: 8 January 2024 Cisco
7 July 2023
IETF Policy Interactions
draft-cooper-policy-interactions-00
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.
Nottingham & Cooper Expires 8 January 2024 [Page 1]
Internet-Draft IETF Policy Interactions July 2023
Copyright Notice
Copyright (c) 2023 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Policy Interactions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Encryption and Access to Communications . . . . . . . . . 3
2.2. DNS-over-HTTPS (DOH) . . . . . . . . . . . . . . . . . . 3
2.3. TLS Encrypted Client Hello (ECH) . . . . . . . . . . . . 4
2.4. Voice over IP . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Emergency services . . . . . . . . . . . . . . . . . . . 4
2.6. Caller identity authentication . . . . . . . . . . . . . 4
2.7. Messaging interoperability . . . . . . . . . . . . . . . 4
2.8. TV whitespaces database protocol . . . . . . . . . . . . 5
2.9. Broadband measurement . . . . . . . . . . . . . . . . . . 5
2.10. Incident response . . . . . . . . . . . . . . . . . . . . 5
2.11. P2P congestion control . . . . . . . . . . . . . . . . . 5
2.12. Internet Architecture Board (IAB) . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
(https://github.com/coopdanger/draft-ietf-policy-interactions).
Nottingham & Cooper Expires 8 January 2024 [Page 2]
Internet-Draft IETF Policy Interactions July 2023
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/
(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
(https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-
protocols-such-as-tls-1-3-doh-dot-esni/) * GCHQ sends 'warning' to
Google and Mozilla over DoH
(https://www.telegraph.co.uk/news/2019/05/31/gchq-warns-google-
mozilla-plans-encrypted-browsers/) * Congressional scrutiny of DoH
(https://hub.packtpub.com/googles-dns-over-https-encryption-plan-
faces-scrutiny-from-isps-and-the-congress/)
Nottingham & Cooper Expires 8 January 2024 [Page 3]
Internet-Draft IETF Policy Interactions July 2023
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
(https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-
protocols-such-as-tls-1-3-doh-dot-esni/) * ESNI blocked in China
(https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-
https-traffic-using-tls-1-3-and-esni/)
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.
Nottingham & Cooper Expires 8 January 2024 [Page 4]
Internet-Draft IETF Policy Interactions July 2023
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
Nottingham & Cooper Expires 8 January 2024 [Page 5]
Internet-Draft IETF Policy Interactions July 2023
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, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<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, 6 April 2023,
<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, May 2015,
<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, June 2022,
<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, August 1996,
<https://www.rfc-editor.org/rfc/rfc1984>.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
DOI 10.17487/RFC2804, May 2000,
<https://www.rfc-editor.org/rfc/rfc2804>.
Nottingham & Cooper Expires 8 January 2024 [Page 6]
Internet-Draft IETF Policy Interactions July 2023
[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, June 2002,
<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, August 2002,
<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, August 2008,
<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, July 2009,
<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, May
2014, <https://www.rfc-editor.org/rfc/rfc7258>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <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, July 2015,
<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, December 2015,
<https://www.rfc-editor.org/rfc/rfc7713>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
<https://www.rfc-editor.org/rfc/rfc7816>.
[RFC8110] Harkins, D., Ed. and W. Kumari, Ed., "Opportunistic
Wireless Encryption", RFC 8110, DOI 10.17487/RFC8110,
March 2017, <https://www.rfc-editor.org/rfc/rfc8110>.
Nottingham & Cooper Expires 8 January 2024 [Page 7]
Internet-Draft IETF Policy Interactions July 2023
[RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for
HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,
<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, February 2018,
<https://www.rfc-editor.org/rfc/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/rfc/rfc8225>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<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, May 2019,
<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, November 2021,
<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, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Authors' Addresses
Mark Nottingham
Cloudflare
Email: mnot@mnot.net
Alissa Cooper
Cisco
Email: alcoop@cisco.com
Nottingham & Cooper Expires 8 January 2024 [Page 8]
