[tsvwg] Roman Danyliw's No Objection on draft-ietf-tsvwg-transport-encrypt-20: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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.