Document shepherd write-up:
Considerations around Transport Header Confidentiality, Network
Operations, and the Evolution of Internet Transport Protocols
draft-ietf-tsvwg-transport-encrypt-17
1. Summary
Document Shepherd: David Black
Responsible AD: Martin Duke
To protect user data and privacy, Internet transport protocols have
supported payload encryption and authentication for some time. Such
encryption and authentication is now also starting to be applied to
the transport protocol headers. This helps avoid transport protocol
ossification by middleboxes, while also protecting metadata about the
communication. Current operational practice in some networks inspect
transport header information within the network, but this is no
longer possible when those transport headers are encrypted.
This document discusses the possible impact when network traffic uses
a protocol with an encrypted transport header. It suggests issues to
consider when designing new transport protocols or features. These
considerations arise from concerns such as network operations,
prevention of network ossification, enabling transport protocol
evolution and respect for user privacy.
This draft is a discussion of design considerations that is intended
"for the general information of the Internet community" making
Informational RFC publication appropriate, as indicated by those words
quoted from Section 4.2.2 of RFC 2026.
While this draft was being developed, RFC 8789 was published which
updates RFC 2026 to require IETF consensus for publication of all
IETF Stream RFCs, including Informational RFCs.
2. Review and Consensus
This draft is one of a number of documents that discuss considerations
and consequences of network header and traffic encryption. Such documents
have been controversial, e.g., RFC 8404 ("Effects of Pervasive Encryption
on Operators") and RFC 8517 ("An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective"), and this draft has not
been an exception. The current draft version is the result of 3 Working
Group Last Calls (WGLCs) to achieve rough consensus in the Working Group
(WG), and that rough consensus includes an open issue to be carried forward
for resolution at IETF Last Call - whether or not this draft is consistent
with IETF consensus on encryption usage, e.g., as reflected in prior RFCs
such as RFC 7258 ("Pervasive Monitoring Is an Attack") and RFC 7624
("Confidentiality in the Face of Pervasive Surveillance: A Threat Model
and Problem Statement"). Whether or not this draft is consistent with
IETF consensus is itself a matter of IETF consensus that is appropriate
to determine at IETF Last Call.
From the outset, this draft has been intended as a discussion of design
considerations that refrains from making protocol design recommendations.
WG development of this draft was uneventful until the first WGLC on the
-08 version of the draft. That WGLC was cross-posted to the Internet
and Security Areas, inviting their comments, and extensive input was
received from both areas. The first WGLC showed significant support
for RFC publication of the draft and recognition of the usefulness of
its contents, although the first WGLC was not successful.
The crucial conclusion of the first WGLC was that the draft was overly
critical of transport header encryption - to quote one of the commenters
(Christian Huitema):
Much of the draft reads like a lamentation of the horrible
consequences of encrypting transport headers ...
(https://mailarchive.ietf.org/arch/msg/tsvwg/ctPi-nysGSrUNRl_slM8HNYNl60/)
In light of this outcome, the draft was extensively rewritten in
consultation with a number of the commenters to better balance the draft
with an overall goal of taking a roughly neutral stance on transport
header encryption - neither in favor of nor opposed to, but rather with
a primary purpose of explaining some design considerations. Numerous
other WGLC suggestions for improved text were also incorporated.
The resulting -12 version of the draft was sent to a second WGLC, again
cross-posted to the Internet and Security Areas to invite comments.
The results of the second WGLC were generally positive - overall support
for the draft and significant suggestions for improved text, but with two
significant issues raised against publication of the draft:
1. No useful guidance to protocol designers (David Schinazi)
2. Not consistent with IETF consensus on encryption (Eric Rescorla)
(https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/)
The announcement of the intended conclusion of this second WGLC during
an interim meeting resulted in a process concern being raised to the
Area Director (AD) that in light of those two issues having been raised,
the second WGLC did not demonstrate sufficient WG rough consensus for
RFC publication of the draft to proceed.
In consultation with the AD and the individual who raised the process
concern, after suggestions for improved text were incorporated, a limited
scope 3rd WGLC was conducted to address the process concern and the two
underlying significant issues on which it was based, as well as check
text improvements made in response to comments during the second WGLC:
https://mailarchive.ietf.org/arch/msg/tsvwg/UIw6tgdSs3AzOc3CFZgwR7HKk7A/
The 3rd WGLC demonstrated WG rough consensus for RFC publication of the
draft and WG rough consensus to dismiss the first significant issue
("No useful guidance") as requesting (in the WG's view) unwarranted
scope expansion of the draft, as announced here:
https://mailarchive.ietf.org/arch/msg/tsvwg/Y0Kw-gL33aa7FLki5Et31oqKajM/ .
The second significant issue noted above on consistency with IETF consensus
is more involved, as described in the conclusion of the 3rd WGLC:
The issue of this draft not being consistent with IETF consensus on
encryption usage is long-standing, having been raised at the first
WGLC on this draft, and it is also equally long-disputed, likewise
since the first WGLC on this draft.
Resolving that issue entails determining the IETF consensus with respect
to this draft, as announced in the conclusion of the 3rd WGLC:
In consultation with the responsible Area Director (Martin Duke), the
chosen path forward to a conclusion on this issue is to consult the
IETF community on IETF consensus via an IETF Last Call. The fact that
IETF consensus (or lack thereof) on this draft is unknown and needs
to be determined will be explicitly noted in the shepherd writeup
for this draft and should be explicitly mentioned in the IETF Last
Call announcement for this draft.
This shepherd writeup hereby takes explicit note of that issue and
requests that it be explicitly mentioned in the IETF Last Call announcement.
Resolution of this issue should keep in mind that the 3rd WGLC clearly
demonstrated WG rough consensus in favor of RFC publication of this draft.
See the announcement of the 3rd WGLC conclusion for details:
https://mailarchive.ietf.org/arch/msg/tsvwg/Y0Kw-gL33aa7FLki5Et31oqKajM/
3. Intellectual Property
The draft authors have stated their direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.
4. Other Points
idnits found an RFC 2119 keyword in text quoted from another RFC, although
this draft contains neither the requisite boilerplate nor a reference
to RFC 2119. That is not a problem for text quoted from another RFC.
idnits also found an Internet-Draft that has been updated, which is also
not a problem.
This draft informatively references draft-ietf-tsvwg-rtcweb-qos, part of
the infamous cluster 238 at the RFC Editor. The shepherd looks forward
to seeing an idnits complaint that the referenced rtcweb-qos draft has
been published as an RFC :-).
A concern has been raised privately that RFC 8789 changed the publication
rules and requirements for this draft rather late in the game, as publication
of RFC 8789 occurred during the 3rd WGLC of this draft.