[tsvwg] Roman Danyliw's No Objection on draft-ietf-tsvwg-transport-encrypt-20: (with COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Thu, 08 April 2021 00:58 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD8C3A313A; Wed, 7 Apr 2021 17:58:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tsvwg-transport-encrypt@ietf.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org, David Black <david.black@dell.com>, david.black@dell.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.27.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <161784352272.11027.18307884467190367053@ietfa.amsl.com>
Date: Wed, 07 Apr 2021 17:58:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Isz6iOTOg7UCLiFHDtcVij3p9YY>
Subject: [tsvwg] Roman Danyliw's No Objection on draft-ietf-tsvwg-transport-encrypt-20: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2021 00:58:43 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-tsvwg-transport-encrypt-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 1. Per “This document discusses some implications of transport header encryption for network operators, researchers, and others …”, who are these “others”? Section 1. Editorial. Make it clearer that this is on-path observation. OLD Such transport header encryption makes it difficult to observe transport protocol behaviour within the network NEW Such transport header encryption makes it difficult to observe transport protocol behaviour from the vantage point of the network. ** Section 2. This sections seems to have a comprehensive treat of various network management functions. Missing for me is an organized set of references for the “security use case”. This doesn’t invalidate the other uses cases, but makes this analysis incomplete. A few examples might be: * security audit (e.g., compliance with ciphersuites) * client and application fingerprinting for inventory and anomaly detection * DDoS mitigation (mentioned as a security consideration) * Inspection of transport headers for NIDS/NGFW/etc alerting on (mentioned generally as anomaly detection) ** Section 2.1. Per “When transport header information cannot be observed, this removes information that could have been used to classify flows by passive observers along the path.”, it might be worth mentioned that it’s common practice to also do various traffic analysis heuristics relying on timing, volumes of information, and correlation between multiple flows to classify protocols too ** Section 2.3.6. This section seems to be emphasizing that any changes in protocols may incur a cost on operators by requiring new tooling or practices. The introduction of this document discussed ossification something that presents its own set of costs. Perhaps this section might be the place to talk about how the lack of header encryption leads to ossification which introduces an another kind of cost for migration cost. ** Section 2.3.6. Editorial. OLD Changes to the transport, whether to protect the transport headers, introduce a new transport protocol, protocol feature, or application might require changes to such tools, and so could impact operational practice and policies. NEW Any introduction of a new transport protocol, protocol feature, or application might require changes to such tools, and so could impact operational practice and policies. ** Section 3. Section 2 used an effective pattern of providing protocol examples. This section would be strengthened by providing concrete examples of where weakening the security properties of a production protocol to support researchers’ (not operators) need for visibility provided eventual, tangible benefit to operators or users. ** Section 3.1. I don’t follow the intent of this section. I understand that the research community needs to make measurements, but I don’t understand what additional measures are used beyond those outlined in Section 2.*. If those in Section 2.* lose visibility so do the researchers in Section 3.*. Is it possible to more clearly describe the circumstances where those in Section 2.* keep visibility and the user community of this section does not? Can the text illuminate how “independent measurement” is different technically than measurement by the “operator”? ** Section 4. The use of transport header authentication and encryption therefore exposes a tussle between middlebox vendors, operators, applications developers and users: o On the one hand, future Internet protocols that support transport header encryption assist in the restoration of the end-to-end nature of the Internet by returning complex processing to the endpoints, since middleboxes cannot modify what they cannot see, and can improve privacy by reducing leakage of transport metadata. o On the other hand, encryption of transport layer information has implications for people who are responsible for operating networks, and researchers and analysts seeking to understand the dynamics of protocols and traffic patterns. I agree that the actors in this “tussle” are “middlebox vendors, operators, application developers and users”. Thanks for making this taxonomy. For completeness, the researchers to whom Section 3 is devoted is missing. Please apply this taxonomy and name these actors relative to the subsequent text. With the lens of these named actors, the framing of the two sub-bullets is vague and duplicative. Per the first bullet on the E2E principle, middlebox vendors don’t deploy their own systems. It’s operators who buy them (or build their own middle boxes) to gain visibility/management into the activity of the users and associated services. The tussle is users who want improved privacy vs. operators/middle-box vendors who want insight into the traffic. Per the second bullet, is a restatement of the above. A variety of parties (operators/researchers) want visibility into the traffic patterns of the users. The trade-off discussed seem pretty limited to only the “user vs. everyone else”. ** Section 4. The text on Authenticating the Transport Protocol Header mixes integrity and authenticity. These are different security properties. ** Section 6. I had difficulty aligning the benefits of this OAM protocol discussion against the pressing challenges outlined in Sections 2 and 3. Does a protocol with encrypted headers become less concerning per those uses cases as a result of OAM in some way? The text immediately jumps into architecture concepts of OAM for which the rest of the text (didn’t for me) so easily fit. Is this guidance for operators or protocol designers? ** Section 7. I don’t follow the substance of the “Supporting Common Specification” bullet item. The presence or absence of header encryption seems orthogonal to making a “common, open specifications”. How do encrypted headers breach the “social contract that maintains the stability of the internet”? ** Section 8. “Open standards motivate a desire for this evaluation to include independent observation …”, I don’t follow how the process used to develop the standard or perhaps its subsequent unrestricted licensing creates any push to then necessarily support evaluation and performance of real-world usage. If this is a motivation, perhaps “open standard” can be more clearly defined.
- [tsvwg] Roman Danyliw's No Objection on draft-iet… Roman Danyliw via Datatracker
- Re: [tsvwg] draft-ietf-tsvwg-transport-encrypt-20… Gorry Fairhurst
- Re: [tsvwg] Roman Danyliw's No Objection on draft… Gorry Fairhurst