[tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Eric Rescorla <ekr@rtfm.com> Sun, 03 November 2019 22:20 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023C5120024 for <tsvwg@ietfa.amsl.com>; Sun, 3 Nov 2019 14:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JYcMvLvjr3d for <tsvwg@ietfa.amsl.com>; Sun, 3 Nov 2019 14:20:07 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB4C1200FA for <tsvwg@ietf.org>; Sun, 3 Nov 2019 14:20:07 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id b20so10793033lfp.4 for <tsvwg@ietf.org>; Sun, 03 Nov 2019 14:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=b1nnSiX3hvcWN27Y4h7oHoMR73kJmhsoIxIUubEOJBo=; b=lD6qaQALuCly/zJSfzhwum61glBzdD/xHZJBh3SHQLZHEy437EyW0mc0qkFMwUfDP5 nr++GlADS1zr8F2SALGxceXe56+a3nb0NwasnFI7mi9aOCdZr1w/NAX7UxCPypMH+vej rq5WZo5C/HL5v/N3KxF7FzUAzlfJytfagNfVA8Nqp1ez6LAcrB5Aqh6WLbHw8vs85Xxd Z992U04fgXb4D2MMjG6pdtEu4HQ+7sx/Bp4+c92oThgc+8I51Co0MPdJpOMfTxpwAaoF E7NiODpEgF393MteZpU+Nz23CjgYu26jTNeBsapLHrq02zmkpBTsa9dxfLugRsEK/x9w Tmag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b1nnSiX3hvcWN27Y4h7oHoMR73kJmhsoIxIUubEOJBo=; b=CEPRUojaSkEZleb+hs14Hv7RWXPRmGWfotxwtjS0WLsWOtbEtNNCRG1Q8NLHoA3U+/ 7efTEuswXVG2D2z9Xe8HEdxbNfJ+kjMPqQ/eacbJ2wFXMwBtyz9xF5WOE7RQZtU8FYsr Hmol2ffFduZWnMjLvN5x3VtQc+ee0I1THx1E4zLhZkZuntKoZ3kBTRljNGYuXAM6kmKj cDTKVaogDd+lPsY1ujicEwtMz+AEtc8uVK7MO+F/AxMsNHyoqjCpKu06X21Fp+cEVoyG CktkRQGTSEgTFimd9xRJS7dheFWFHfOuqc2aJyK9F1bORQk21fra56gVtbY5e9SJLXu9 pbiw==
X-Gm-Message-State: APjAAAWrRuqEItEhNBWIYLHBZLzlIEBHpz3iHVfU9cGJGIu/Dd0mLhEA +wnHiZQ1wtnGLW0VKmQhzaxyaVB9By3u0L5dGm57TdOqbUw=
X-Google-Smtp-Source: APXvYqyqoJIWFa3ppbHpjsgtQgcYeomm2/iJ2YqmC3ZHgnLOpuabnnsav1Xjtkg7PWJLdczCFO3U09GrPTXVpjC7fc8=
X-Received: by 2002:a19:c6d6:: with SMTP id w205mr13311657lff.17.1572819604911; Sun, 03 Nov 2019 14:20:04 -0800 (PST)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 3 Nov 2019 14:19:28 -0800
Message-ID: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com>
To: tsvwg IETF list <tsvwg@ietf.org>, saag@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d8c9ae0596789900"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TdiTNveeQnujgl7WD-J6JETRGH4>
Subject: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Sun, 03 Nov 2019 22:20:11 -0000

After reviewing this document, I share Christian Huitema's concern
about the tone and perspective of this document, which, while saying
that encryption is good, then proceeds to mostly lament how difficult
it makes life for various entities other than the endpoints. It seems
to me rather problematic to publish this document as an RFC for
several reasons:

- Yes, it's true that the trend towards encrypting everything has
  and continues to make a number of entities sad, but that's a point
  which is already made in RFC 8404. How does all of the additional
  detail here help?

- The community of people designing new transport protocols has
  already weighed all the considerations here and come down pretty
  decisively on the side of "encrypt all the things". Given that
  both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely
  we're going to design a new transport protocol that doesn't.

- Having an IETF Consensus RFC that is so heavily weighted on the side
  of "this is how encryption inconveniences us" and so light on "these
  are the attacks we are preventing" gives a misleading picture of the
  IETF community's view of the relative priority of these
  concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far more
  closely reflects that consensus.

In short, I do not think this draft should be published as an RFC.

I have appended a number of detailed comments which IMO need to be
addressed in any case, but even if they were resolved, that would not
address my primary concern.


COMMENTS
S 2.1.
>   2.1.  Use of Transport Header Information in the Network
>
>      In-network measurement of transport flow characteristics can be used
>      to enhance performance, and control cost and service reliability.
>      Some operators have deployed functionality in middleboxes to both
>      support network operations and enhance performance.  This reliance on

This seems like a contested point. My understanding is that while
these middleboxes are *intended* to enhance performance that there is
doubt that they actually do.


S 2.1.
>      to enhance performance, and control cost and service reliability.
>      Some operators have deployed functionality in middleboxes to both
>      support network operations and enhance performance.  This reliance on
>      the presence and semantics of specific header information leads to
>      ossification, where an endpoint could be required to supply a
>      specific header to receive the network service that it desires.  In

Well, not just the network service it desires but *any* service.


S 2.1.
>      specific header to receive the network service that it desires.  In
>      some cases, this could be benign or advantageous to the protocol
>      (e.g., recognising the start of a connection, or explicitly exposing
>      protocol information can be expected to provide more consistent
>      decisions by on-path devices than the use of diverse methods to infer
>      semantics from other flow properties).  In other cases, the

Is there evidence of this?


S 2.1.
>
>      As an example of ossification, consider the experience of developing
>      Transport Layer Security (TLS) 1.3 [RFC8446].  This required a design
>      that recognised that deployed middleboxes relied on the presence of
>      certain header filed exposed in TLS 1.2, and failed if those headers
>      were changed.  Other examples of the impact of ossification can be

I think you mean "fields" and it wasn't headers so much as handshake
data.


S 2.2.
>      This supports use of this information by on-path devices, but at the
>      same time can be expected to lead to ossification of the transport
>      header, because network forwarding could evolve to depend on the
>      presence and/or value of these fields.  To avoid unwanted inspection,
>      a protocol could intentionally vary the format or value of exposed
>      header fields [I-D.ietf-tls-grease].

It's not just a matter of unwanted inspection. There's a real question
about whether we want these on-path devices to have this information
at all, as it is potentially used for surveillance, traffic
analysis, etc.



S 2.2.
>
>      While encryption can hide transport header information, it does not
>      prevent ossification of the network service.  People seeking to
>      understand network traffic could come to rely on pattern inferences
>      and other heuristics as the basis for network decision and to derive
>      measurement data.  This can create new dependencies on the transport

This also seems quite contested. Do you have any evidence of such a
thing happening?


S 2.3.
>         anomalies, and failure pathologies at any point along the Internet
>         path.  In many cases, it is important to relate observations to
>         specific equipment/configurations or network segments.
>
>         Concealing transport header information makes performance/
>         behaviour unavailable to passive observers along the path,

While also making traffic analysis more difficult.


S 2.3.
>         applications it is important to relate observations to specific
>         equipment/configurations or particular network segments.
>
>         Concealing transport header information can make analysis harder
>         or impossible.  This could impact the ability for an operator to
>         anticipate the need for network upgrades and roll-out.  It can

Or to reduce the opportunities for traffic discrimination.


S 2.3.
>
>      Different parties will view the relative importance of these issues
>      differently.  For some, the benefits of encrypting some, or all, of
>      the transport headers may outweigh the impact of doing so; others
>      might make a different trade-off.  The purpose of highlighting the
>      trade-offs is to make such analysis possible.

This whole section seems to really just ignore the fact that many of
these practices are unwanted.


S 3.1.
>      Firewalls).  Common issues concerning IP address sharing are
>      described in [RFC6269].
>
>   3.1.  Observing Transport Information in the Network
>
>      If in-network observation of transport protocol headers is needed,

Why is this needed? I know some people might want it.


S 3.1.1.
>   3.1.1.  Flow Identification Using Transport Layer Headers
>
>      Flow identification is a common function.  For example, performed by
>      measurement activities, QoS classification, firewalls, Denial of
>      Service, DOS, prevention.  This becomes more complex and less easily
>      achieved when multiplexing is used at or above the transport layer.

Also traffic discrimination and blocking.


S 3.1.1.
>      use heuristics to infer that short UDP packets with regular spacing
>      carry audio traffic.  Operational practices aimed at inferring
>      transport parameters are out of scope for this document, and are only
>      mentioned here to recognize that encryption does not prevent
>      operators from attempting to apply practices that were used with
>      unencrypted transport headers.

This has a really threatening tone. If you don't give us what we want,
look what could happen.


S 3.1.2.
>
>      This information can support network operations, inform capacity
>      planning, and assist in determining the need for equipment and/or
>      configuration changes by network operators.  It can also inform
>      Internet engineering activities by informing the development of new
>      protocols, methodologies, and procedures.

What is the point of this exhaustive list?


S 3.1.3.
>
>         AQM and ECN offer a range of algorithms and configuration options.
>         Tools therefore need to be available to network operators and
>         researchers to understand the implication of configuration choices
>         and transport behaviour as the use of ECN increases and new
>         methods emerge [RFC7567].

QUIC sort of hides ECN feedback but not ECN marking.


S 3.2.4.
>
>         A network operator needs tools to understand if datagram flows
>         (e.g., using UDP) comply with congestion control expectations and
>         therefore whether there is a need to deploy methods such as rate-
>         limiters, transport circuit breakers, or other methods to enforce
>         acceptable usage for the offered service.

Does it *need* it or does it just want it. Note that we have had DTLS-
SCTP with WebRTC without this property for some time now. Can you provide
some evidence that operators have been inconvenienced by not having it.


S 3.3.
>      operators bring together heterogeneous types of network equipment and
>      seek to deploy opportunistic methods to access radio spectrum.
>
>      A flow that conceals its transport header information could imply
>      "don't touch" to some operators.  This could limit a trouble-shooting
>      response to "can't help, no trouble found".

We have quite a bit of QUIC traffic now. I'd be interested in hearing
from the gQUIC team whether they have seen anything like this.


S 4.
>
>      There are several motivations for encryption:
>
>      o  One motive to use encryption is a response to perceptions that the
>         network has become ossified by over-reliance on middleboxes that
>         prevent new protocols and mechanisms from being deployed.  This

This isn't just a perception, it's a demonstrable reality.


S 4.
>
>      o  One motive to use encryption is a response to perceptions that the
>         network has become ossified by over-reliance on middleboxes that
>         prevent new protocols and mechanisms from being deployed.  This
>         has lead to a perception that there is too much "manipulation" of
>         protocol headers within the network, and that designing to deploy

Not just manipulation, also inspection.


S 4.
>
>         One example of encryption at the network layer is the use of IPsec
>         Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode.
>         This encrypts and authenticates all transport headers, preventing
>         visibility of the transport headers by in-network devices.  Some
>         VPN methods also encrypt these headers.

This seems like a bad example as part of the point of a VPN is to
conceal the headers form the network.


S 6.1.
>
>   6.1.  Independent Measurement
>
>      Independent observation by multiple actors is important if the
>      transport community is to maintain an accurate understanding of the
>      network.  Encrypting transport header encryption changes the ability

This is ironic because QUIC is much better for endpoint measurement
than TCP because the details are accessible at the application layer.


S 8.
>      example, an attacker could construct a DOS attack by sending packets
>      with a sequence number that falls within the currently accepted range
>      of sequence numbers at the receiving endpoint, this would then
>      introduce additional work at the receiving endpoint, even though the
>      data in the attacking packet may not finally be delivered by the
>      transport layer.  This is sometimes known as a "shadowing attack".

This doesn't seem to be an issue with protocols that authenticate the SN.


S 8.
>
>      An attack can, for example, disrupt receiver processing, trigger loss
>      and retransmission, or make a receiving endpoint perform unproductive
>      decryption of packets that cannot be successfully decrypted (forcing
>      a receiver to commit decryption resources, or to update and then
>      restore protocol state).

This is not a real issue for QUIC or similar protocols