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

[Kathleen Moriarty <[e-mail]>]

On Mon, Nov 4, 2019 at 10:00 AM Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

> Hi Ekr,
>
>
>
> see inline, marked [MK]…
>
>
>
> Mirja
>
>
>
>
>
> *From: *Eric Rescorla <[e-mail]>
> *Date: *Monday, 4. November 2019 at 14:57
> *To: *Mirja Kuehlewind <[e-mail]>
> *Cc: *Tom Herbert <[e-mail]>, tsvwg IETF list <[e-mail]>,
> "[e-mail]" <[e-mail]>
> *Subject: *Re: [tsvwg] Comments on
> draft-ietf-tsvwg-transport-encrypt-08.txt
>
>
>
>
>
>
>
> On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind <
> [e-mail]> wrote:
>
> Hi Ekr, hi all,
>
> Just on this part:
>     > - 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.
> I disagree that this is the conclusion the community came to, otherwise we
> would not have put a signal for the network in the QUIC header. Also
> encryption has a cost and that's the discussion we continuously still
> having in QUIC and well as other working groups. So "encrypt all the
> things" is way too simplified and for sure not a consensus statement which
> this draft (draft-ietf-tsvwg-transport-encrypt) clearly shows.
>
>
>
> Well, we put a single, optional, bit in the header and everything else we
> could figure out how to encrypt encrypted. It's true that encryption has a
> cost to the design of the protocol and to the endpoint implementations and
> we've been trying to balance that cost against the value, but that's not
> because the group isn't trying to encrypt as much as possible.
>
>
>
> [MK]I don’t think we need to nit-pick here but I think "encrypt all the
> things" and “encrypt as much as possible” is not the same, especially as
> “possible” is something to argue about when it comes to the question of how
> much you are willing to pay. However, I don’t think we need to discuss this
> in details here, just wanted to say that I don’t think the situation is a
> simple as you have stated and I don’t think there is consensus for a simple
> "encrypt all the things".
>
>
>
> I certainly realize that there are people who are sad about this -- as you
> rightly point out reflected in this draft –
>
>
>
> [MK] I don’t think people are sad about increasing amount of encryption.
> But when we change things we also need to have a discussion of the
> implication of this change and cannot just close our eyes. As I said in
> some cases we might be happy about things that hopefully just go away, in
> other cases it may actually have more severe impact of the viability of the
> Internet as a interconnected network that is operated by different entities.
>
>
>
> but I believe they are in the rough, at least of the community of people
> actively designing and deploying new protocols.
>
>
>
> [MK] I don’t believe this. Otherwise I wondering why we had such a lengthy
> discussion for more than a year in the QUIC working group.
>
>
>
> Do you see any plausible situation in which a new transport protocol isn't
> largely encrypted?
>
>
>
> [MK] That’s not the intention here. But we also need to consider ways to
> interact with the network where this brings benefit to both the network and
> the performance of the end-to-end traffic. There are situation where this
> is the case. And I don’t think one makes sense without the other.
>
>
>

I agree with Mirja.  I don't think there is consensus to ignore the
problems.   If the issues to operators are not enumerated and allowed to be
discussed, a way forward for increased deployment of strong e2e is much
more difficult.  Discussing problems enables a way to create a path forward
and will likely lead to faster deployment of strong e2e. People will be
resistant if problems are minimally not discussed, if not addressed in
other ways.

Best regards,
Kathleen


>
>
>
>
>
> -Ekr
>
>
>
>
> Mirja
>
>
>
> On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>     On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla <[e-mail]> wrote:
>     >
>     > 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 believe the problem with this draft is that it identifies a
>     perceived problem, but does little to offer a solution other than
>     saying don't encrypt the transport layer header. As I've mentioned
>     several times, putting transport layer information of interest into
>     HBH extension headers is the architecturally correct solution for
>     hosts to signal the network. This works with any transport layer
>     protocol and exposure of transport layer information to the network is
>     under explicit control of the end host. IMO, the draft does not
>     adequately explore this alternative solution and too easily just
>     brushes it off as being "undesirable" based on one set of snapshot
>     measurements that is now almost four years old.
>
>     > 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.
>
>     QUIC presents a problem in itself since the QUIC harders are inside
>     the UDP payload so intermediate devices end up needing to parse the
>     UDP transport payload. I believe the only way to identify a QUIC
>     packet is by matching port numbers, but per RFC7605 interpretation of
>     port numbers in the middle of the network is prone to
>     misinterpretation. Eventually, something that looks like a QUIC packet
>     based on port number will be misinterpreted. Looking at
>     draft-ietf-quic-transport-23, I don't see any discussion about this or
>     reference to RFC7605. Note this is true for any use case of UDP
>     including transport layer or network layer encapsulation. Even if the
>     argument is that the information is only being read and
>     misinterpretation is innocuous, it still wouldn't be robust protocol.
>     This can be contrasted to putting the information in HBH options which
>     can be correctly and unambiguously identified anywhere in the network.
>
>     Tom
>
>     >
>     >
>     > 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
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>


-- 

Best regards,
Kathleen