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

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Nov 2019 14:19:28 -0800

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

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 3 Nov 2019 16:11:06 -0800

This document appears to have a *lot* of overlap with RFC 8404. So given that the basic point has already been made, it seems to me that this document needs to focus on new points and/or practical recommendations to make its publication worthwhile.

The issues raised here are by no means new - they first arose with the introduction of IPsec. Endpoint monitoring makes it possible for endpoint owners to collect information on performance that they can choose to share with operators. 

Thus the issue here is not really the loss of transport performance information since that remains available if consent can be obtained, but rather the collection of that information by unauthorized third parties.

> On Nov 3, 2019, at 2:20 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> S 2..2.
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Tom Herbert <[email-masked]>
Date: Sun, 3 Nov 2019 18:15:05 -0800

> 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.

> 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

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Nov 2019 14:17:19 +1100

On Mon, Nov 4, 2019, at 13:15, Tom Herbert wrote:
> reference to RFC7605. 

Please refer to draft-ietf-quic-manageability for that discussion.

Note that while there has been extensive discussion on what QUIC should expose in terms of loss and latency, I recall relatively little discussion about distinguishing QUIC from other protocols outside of the narrow context of ensuring that QUIC can be effectively multiplexed with certain other protocols.

My sense is that some people are assuming that they can use port numbers, which are fraught for the reasons you identify.  Others might choose to infer the use of QUIC using the "QUIC bit": the 0x40 bit in QUIC version 1 is fixed.  

Personally, I think that endpoints are not obligated to signal which protocol they are using to the network.  Maybe the QUIC bit is that signal and I'm just in denial.  I guess we'll see whether I can send packets with a 0 value for that bit...

> can be correctly and unambiguously identified anywhere in the network.

I happen to agree, though I don't think that this is as simple as you might be implying.  https://tools.ietf.org/html/rfc8558 makes a similar assertion, but identifies some of the underlying complexities.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 4 Nov 2019 09:14:43 +0000

Hi Ekr, hi all,

    >   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.

Mirja

On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Tom

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 4 Nov 2019 09:26:41 +0000

Hi Bernard, hi all,

please see below, marked with [MK].

Mirja

On 04.11.19, 01:11, "tsvwg on behalf of Bernard Aboba" <[email-masked] on behalf of [email-masked]> wrote:

[MK] Yes, these issues are not new but that makes it even more important to document them in a well written RFC, so we have a common basis for any further discussion. RFC8404 touches these points but also others. This document has a more narrow focus and gives more detail which I think is valuable for future discussion and therefore I support publication of this document.

[MK] The issue here IS loss of visibly. Yes it's not great that we have all the mechanisms in the network now that use the information that were not supposed to be used by the network. However, we can't deny that if we change the end-to-end protocol that this will have an impact on the network and how we mange networks today. In some cases we can be happy that some of the boxes will just go away but in other case this can cause problems and can noticeably impact end-to-end performance, e.g. when an operator is not able to quickly locate the root cause of a problem anymore.

[MK] Providing equivalent information based on consent is the solution to the problem described in this draft and something we should be working on but is not there yet.

[MK] Collection of information by unauthorized third party is another problem which still exists and is now just shifted to another layer but would for sure need another draft (or multiple ones).

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Nov 2019 05:56:31 -0800

On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind <
[email-masked]> wrote:

> 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.

I certainly realize that there are people who are sad about this -- as you
rightly point out reflected in this draft -- but I believe they are in the
rough, at least of the community of people actively designing and deploying
new protocols. Do you see any plausible situation in which a new transport
protocol isn't largely encrypted?

-Ekr

> Mirja
>
>
>
> On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" <
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 4 Nov 2019 14:59:40 +0000

Hi Ekr,

see inline, marked [MK]…

Mirja

From: Eric Rescorla <[email-masked]>
Date: Monday, 4. November 2019 at 14:57
To: Mirja Kuehlewind <[email-masked]>
Cc: Tom Herbert <[email-masked]>, tsvwg IETF list <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ekr, hi all,

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.

-Ekr

Mirja

On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Tom

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 4 Nov 2019 11:15:57 -0500

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

> Hi Ekr,
>
>
>
> see inline, marked [MK]…
>
>
>
> Mirja
>
>
>
>
>
> *From: *Eric Rescorla <[email-masked]>
> *Date: *Monday, 4. November 2019 at 14:57
> *To: *Mirja Kuehlewind <[email-masked]>
> *Cc: *Tom Herbert <[email-masked]>, tsvwg IETF list <[email-masked]>,
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [tsvwg] Comments on
> draft-ietf-tsvwg-transport-encrypt-08.txt
>
>
>
>
>
>
>
> [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".
>
>
>
> 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.
>
>
>
> [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

-- 

Best regards,
Kathleen

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Nov 2019 08:16:48 -0800

On Mon, Nov 4, 2019 at 6:59 AM Mirja Kuehlewind
<[email-masked]> wrote:
> On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind <[email-masked]> wrote:
>
> Hi Ekr, hi all,
>
> Just on this part:

Mirja,

Yes, that is true. We need a way to allow hosts to signal the network.
But doing this in the transport layer is architecturally incorrect,
has led to protocol ossification, isn't robust like in the case of
QUIC, presents a security and privacy risk, and doesn't scale beyond
supporting one or maybe two transport protocols. Expliciting signaling
contained in the network layer headers that is under control of the
sending host is the correct alternative IMO.

Tom

---

From: Christian Huitema <[email-masked]>
Date: Mon, 4 Nov 2019 08:29:04 -0800

On 11/4/2019 6:59 AM, Mirja Kuehlewind wrote:
> ...
>
> 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.
>
We had that discussion, and there were indeed two opposing ideas: on one
hand, expose some information to the path for network management
purpose; on the other hand avoid exposing information to prevent
ossification and interference, and to avoid privacy issues. Only some
the "network management" arguments actually gained some traction:
enabling measurements of network latency, enabling measurement of data
rates, and enabling measurement of packet losses. One of the problem
with the current draft is that it does not distinguish between these
"common ground" objectives and a slew of other "network management"
practices, such as discriminating between flows or interfering with
transport protocols. It also mixes in transport protocol debugging,
which is a different subject.

Just because we have some consensus on the legitimacy of measuring
latency, data rates and packet losses does not mean that we want to
incorporate support in the transport protocol. We quickly realize that
there is nothing particular needed for measuring data rates, beside
separating flows by five tuples and counting packets. We struggled with
the privacy implications of measuring latency, because doing so may
enable triangulation and does enable the detection of proxies. We also
failed to achieve consensus on a specific way to enable packet loss
measurement, because we could not reach consensus on a specific algorithm.

The QUIC working group converged on enabling latency measurements on a
fraction of the flow. It appears that measuring a relatively small
fraction of the flows is sufficient to gather statistically significant
measurements of latency. Ensuring that a sufficient fraction of the
flows is not measurable enables privacy protection for sensitive flows
that need to hide usage of proxies.

The draft does not include this kind of discussions.

> [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.
>

You seem to be arguing for something like "performance enhancing
proxies". End-to-end encryption is indeed a way to opt out of such
proxying. Measurements so far indicate that opting out has very little
impact on actual performance, and that whatever impact there is could be
reduced by improvements in end-to-end algorithms. In fact, in many
cases, end to end performance is better without such proxies. But the
real reason for the opposition to the concept is ossification. Enabling
such proxies would quickly ossify the new transports, and a such there
is a strong consensus in the end-to-end transport designers to use
encryption and prevent interference by such devices.

This does not mean that network level deployment have no role in the
future. I could see for example tunnels deployed that use FEC or local
retransmission to mask the poor performance of a particular subnet. Or I
could see end-to-end devices opting into some kinds of application level
caching services in order to improve performance. But the draft should
be clear: transport protocols do not have to enable interference with
the transport bits.

My take is that this draft should not be published as is. It should be
rewritten to actually reflect the consensus of the transport area, which
has to reflect in particular the work in the QUIC working group.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 4 Nov 2019 08:31:40 -0800

> sending host is the correct alternative IMO.

+1.

We would be better off if we started work on this sooner rather than later.

-- Christian Huitema

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Nov 2019 09:05:23 -0800

[MK] Yes, these issues are not new but that makes it even more important to
document them in a well written RFC, so we have a common basis for any
further discussion. RFC8404 touches these points but also others. This
document has a more narrow focus and gives more detail which I think is
valuable for future discussion and therefore I support publication of this
document.

[BA] I would argue that this work item, even when combined with
draft-ietf-quic-manageability, does not document the current state of
operations and regulation nor the potential solutions in a comprehensive
way. Over the last decade, with the revolution in "big data" and machine
learning, there has been a sea change in the way performance data is
collected, analyzed and regulated.  The move to "cloud services" has
resulted in applications developers (who also represent large consumers and
sometimes operators of network services) routinely collecting large amounts
of performance data (e.g. see:  https://w3c.github.io/webrtc-stats/ ) so as
to support performance analysis and capacity planning. At the same time,
the collection, use and retention of performance data is increasingly
subject to regulation (e.g. GDPR and "network neutrality" regulations,
among others).  Today, to accommodate the increasing concerns by regulators
and civil society, SDOs such as W3C  are conducting increasingly detailed
privacy reviews of their specifications.

This situation is quite different from the  that which existed a decade
ago, when application deployment and monitoring was often a customer
responsibility delegated to network operators, network operations
management techniques were unregulated and operators routinely built
network management systems relying upon Deep Packet Inspection (DPI) and
other snooping techniques.   Given these major changes, documents such as
this one need to acknowledge the changes in operational practice and
broaden their definition of "manageability".

[MK] The issue here IS loss of visibility.

[BA] If appropriate manageability standards are developed, it should still
be possible for applications developers to manage applications and network
performance.  The extent to which this is possible is a good question for
the document to answer - but it does not attempt to answer that question
because it is stuck in a decade-old mindset.

Nothing prevents applications developers from sharing appropriately
aggregated and anonymized data with network operators. What IS lost is the
ability of third parties to collect performance information without
authorization or regulatory scrutiny - but in many parts of the world, that
door closed quite a while ago.

On Mon, Nov 4, 2019 at 1:26 AM Mirja Kuehlewind <
[email-masked]> wrote:

> On 04.11.19, 01:11, "tsvwg on behalf of Bernard Aboba" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     This document appears to have a *lot* of overlap with RFC 8404. So
> given that the basic point has already been made, it seems to me that this
> document needs to focus on new points and/or practical recommendations to
> make its publication worthwhile.
>
>     The issues raised here are by no means new - they first arose with the
> introduction of IPsec. Endpoint monitoring makes it possible for endpoint
> owners to collect information on performance that they can choose to share
> with operators.
>
> [MK] Yes, these issues are not new but that makes it even more important
> to document them in a well written RFC, so we have a common basis for any
> further discussion. RFC8404 touches these points but also others. This
> document has a more narrow focus and gives more detail which I think is
> valuable for future discussion and therefore I support publication of this
> document.
>
>     Thus the issue here is not really the loss of transport performance
> information since that remains available if consent can be obtained, but
> rather the collection of that information by unauthorized third parties.
>
> [MK] The issue here IS loss of visibly. Yes it's not great that we have
> all the mechanisms in the network now that use the information that were
> not supposed to be used by the network. However, we can't deny that if we
> change the end-to-end protocol that this will have an impact on the network
> and how we mange networks today. In some cases we can be happy that some of
> the boxes will just go away but in other case this can cause problems and
> can noticeably impact end-to-end performance, e.g. when an operator is not
> able to quickly locate the root cause of a problem anymore.
>
> [MK] Providing equivalent information based on consent is the solution to
> the problem described in this draft and something we should be working on
> but is not there yet.
>
> [MK] Collection of information by unauthorized third party is another
> problem which still exists and is now just shifted to another layer but
> would for sure need another draft (or multiple ones).
>
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Nov 2019 17:46:26 +0000

Just focussing on the end...

On 04/11/2019, 16:29, Christian Huitema wrote:
> impact on actual performance, and that whatever impact there is could 
> be reduced by improvements in end-to-end algorithms. In fact, in many 
> real reason for the opposition to the concept is ossification. 
> Enabling such proxies would quickly ossify the new transports, and a 
> such there is a strong consensus in the end-to-end transport designers 
> to use encryption and prevent interference by such devices.
>
On PEPs: The current case for many of the network segments I see is that 
QUIC is quite good, but it is considerably worse (currently) than a PEP 
using Split-TCP. That's not to say it can't improve - but that's not 
true yet. However: It's curious that people keep going back to PEPs, 
because network devices that change the transport header were 
specifically out-of-scope for this ID!
> retransmission to mask the poor performance of a particular subnet. Or 
> I could see end-to-end devices opting into some kinds of application 
> level caching services in order to improve performance. But the draft 
> should be clear: transport protocols do not have to enable 
> interference with the transport bits.
>
There are also many operators - e.g., enterprise who rely on the methods 
currently mentioned in this draft. In this case, they also actually *do* 
care about the performance of the networks they operate. They also do 
care about the topics, which matters most depends on which organisation.
> rewritten to actually reflect the consensus of the transport area, 
> which has to reflect in particular the work in the QUIC working group.
>
I suspect the information you wish to see about QUIC's design is 
actually available. I'm not sure documenting QUIC is helpful here, if 
the QUIC WG wants to so that, can't it be added to the manageability draft?

I dispute the claim that the entire transport area has the same 
priorities as that voiced at the QUIC WG. I think this discussion needs 
to look outside the QUIC working group and examine other transports and 
WGs. As far as I know the RTP people are still doing specs in the IETF, 
as are various other transport working groups. Also, this draft has been 
presented at OPsec, and has contributors from other areas outside 
transport...

My assertion is that *current* practice is using transport header 
information & header authentication/encryption is becoming common, let's 
set out what the current facts are. I'm also going to oppose documenting 
new ideas for how we can go forward - as Spencer insisted when this was 
chartered: Proposing new methods belong in a different draft - paraphrased.

Gorry

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 4 Nov 2019 17:54:24 +0000

Hi Tom, hi Christian,

see below.

From: Christian Huitema <[email-masked]>
Date: Monday, 4. November 2019 at 17:32
To: Tom Herbert <[email-masked]>, Mirja Kuehlewind <[email-masked]>
Cc: tsvwg IETF list <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Mirja,

+1.

I agree but in the end we have to be realistic what can be deployed. In case of the spin bit, this is information that is, by chance, measurable in TCP and therefore only a problem with QUIC traffic (for now as long as we don’t develop any new transports). Yes, having a transport-independent method would be even better but if we can get the spin bit deployed and it addresses the problem we have, I’m all for that!

Mirja

-- Christian Huitema

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 4 Nov 2019 18:02:02 +0000

Hi Christian,

please see two comments below (marked with [MK]).

Mirja

On 04.11.19, 18:46, "Gorry Fairhurst" <[email-masked]> wrote:

    > interference with the transport bits.

[MK] This is not what the draft is asking for. 

    > which has to reflect in particular the work in the QUIC working group.

[MK] The purpose of this draft is exactly to find and document consensus in the transport area and in the IETF. I don't think any individual at this points knows what the consensus actually is. This document has support in tsvwg (otherwise it would not have been adopted as wg document) and I also don't think there is anything in the draft that contradicts any work in the QUIC group.

    
    
    Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Nov 2019 18:24:01 +0000

On 04/11/2019, 16:16, Tom Herbert wrote:
>> From: Eric Rescorla<[email-masked]>
>> To: Mirja Kuehlewind<[email-masked]>
>> Cc: Tom Herbert<[email-masked]>, tsvwg IETF list<[email-masked]>, "[email-masked]"<[email-masked]>
>> On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind<[email-masked]>  wrote:
>>
>> Hi Ekr, hi all,
>>
>> Just on this part:
I don't agree that has been the case: The transport-layer specified by 
the IETF has always had elements visible to other layers. (My very first 
job - a little whiole ago - was to look for SYN flags to control access 
at a gateway, we've seen all sorts of signalling methods and protocol in 
transport over the years) - QUIC over UDP reveals the minimal. SRTP 
chose other approaches. TCP, SCTP and a myriad of other protocols have 
been made, and toolkits built around these to support a wide range of 
uses - some good, some bad, etc.

My real hope would be we publish this ID (with more work if needed) and 
move to look to the future!

I am pretty sure we can choose to do other things than transport 
headers. However, this isn't yet where we are. I do agree that explicit 
signaling contained in the network layer headers could seem to be an 
alternative in future - to me, this is also fine in a transport header 
(RTP seems to have done things in this space, etc), but we'd need to all 
agree on where to place the info - using lower-layer methods/tunnels is 
perhaps seems less attractive to me, but may be exactly what some 
operators wish. Is

With relation to the present draft - I understand it is out-of-scope to 
speculate/predict about how do this in future.

Gorry
>>
>>
>> -Ekr
>>
>>
>>
>>
>> Mirja
>>
>>
>>
>> On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert"<[email-masked] on behalf of [email-masked]>  wrote:
>>
>>      On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla<[email-masked]>  wrote:
>>      >
>>      can be correctly and unambiguously identified anywhere in the network..
>>
>>      Tom
>>
>>      >
>>      >
>>      >  S 4.
>>      >  >
>>      >  >          visibility of the transport headers by in-network devices..  Some

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Nov 2019 10:34:29 -0800

> care about the topics, which matters most depends on which organisation.

Gorry,

"Many" is not "all". And even if all operators cared about this, they
will be all over the board about what information they need. If the
draft were to say that items X, Y, and Z are needed to be exposed in
the transport layer then that might be something we can work with and
this would be a different conversation. But, I don't believe you'll
ever get agreement on that. This is _exactly_ the same quandy we got
into we asked the operators what information they needed out of
transport payload when discussing encrypting transport payloads.

So basically what we're left with is plain text transport layer
information _may_ be important for some use case and _may_ have
legitimate reason to be read in the network, but we _can't_ describe
the exact circumstances when the information is required, we _don't_
know what a priori what transport protocols the network can even parse
so it can extract the information, the set of required information is
_undefined_, and we _don't_ have a good assessment of what the
security and privacy risks are. Given this, I still don't see much of
an argument that transport developers shouldn't encrypt as much a
possible-- to me it's clear the benefits outweigh the cost.

> chartered: Proposing new methods belong in a different draft - paraphrased.
Then I suggest to remove any discussion along those lines including
the references to alternatives include the discussion about and the
inherently negative comments about their potential use.

Tom

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Nov 2019 11:10:00 -0800

Gorry said:

"I'm also going to oppose documenting new ideas for how we can go forward"

[BA] The problem is that the "current practices" described in the document
are more representative of where we were 10+ years ago, than where we are
today, with Infrastructure as a Service (IAAS), Platform As A Service,  and
Application as a Service (AAAS) providers all operating at enormous scale,
all measuring performance using "new ideas" (developed largely outside the
IETF).

"The RTP people are still in IETF"

[BA] The way realtime applications performance assessment has been
conducted has changed markedly over the last decade, particularly as the
world has moved toward the development and deployment of web-based
applications (e.g. Electron, React, PWAs, etc.) where performance data is
collected by the Application as a Service Provider rather than the network
operator (though the two may collaborate).

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Nov 2019 19:39:03 +0000

See in-line,

> "I'm also going to oppose documenting new ideas for how we can go forward"
If there are specs we should have included, and are used, I'd be happy 
as always to see these and discover more.
> [BA] The problem is that the "current practices" described in the 
> document are more representative of where we were 10+ years ago, than 
> where we are today, with Infrastructure as a Service (IAAS), Platform 
> As A Service,  and Application as a Service (AAAS) providers all 
> operating at enormous scale, all measuring performance using "new 
> ideas" (developed largely outside the IETF).
>
You seem to have shifted a layer above the IETF transport - and yes it's 
important to understand interactions at this level to understand 
QoE.Many of these service will run on TCP?

This ID is specifically about transport performance - and debugging 
transport v network interactions.
> conducted has changed markedly over the last decade, particularly as 
> the world has moved toward the development and deployment of web-based 
> applications (e.g. Electron, React, PWAs, etc.) where performance data 
> is collected by the Application as a Service Provider rather than the 
> network operator (though the two may collaborate).
>
That may also be common, but many of these seem to be TCP-based 
currently and may transition to QUIC -  are you claiming that all 
operators - enterprises, private networks, small ISPs, large ISP, 
transit, etc all manage using the same tools and only look at apps data? 
That really is not the story I have been hearing.

Gorry
>
>
> On Mon, Nov 4, 2019 at 9:46 AM Gorry Fairhurst <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Nov 2019 20:36:12 -0800

> Please refer to draft-ietf-quic-manageability for that discussion.
Martin,

I looked at that draft. While it does mention RFC7605, the explanation
for how non-QUIC packets that match port 443 aren't misinterpreted
isn't particularly satisfying. Other than assuming port number match
is sufficient, the recommended approach seems to be for middleboxes to
track flows by handshake. But, that then requires state to be
maintained and implies that packets for the flow must be consistently
be routed through the same device (a common problem for any stateful
device in the network). I don't think the QUIC spin bit serves as an
exemplar for reliably exposing transport layer information in a
transport protocol that is otherwise encrypted.

Tom

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 05 Nov 2019 16:09:16 +1100

> transport protocol that is otherwise encrypted.

Yeah, not saying that this is ideal, but it's what we're handing out.  Well, some of us might, I don't think that our implementation has any intention of leaking anything at this stage.

Note also that QUIC allows for migration where the new path will not see the handshake.

I don't think that there is a lack of interest in this subject, just that there is no real drive toward finding e2m and m2e signaling that will be deployed.  Personally, my interests are aligned more with removing signals, not adding them.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Nov 2019 07:10:44 -0800

> I don't think that there is a lack of interest in this subject, just that there is no real drive toward finding e2m and m2e signaling that will be deployed.  Personally, my interests are aligned mo…

That is happening in IPPM WG and others. Options are being defined in
extension headers for the purposes of host to network signaling.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Nov 2019 11:58:55 -0800

On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind <
[email-masked]> wrote:

> [MK] The purpose of this draft is exactly to find and document consensus
> in the transport area and in the IETF. I don't think any individual at this
> points knows what the consensus actually is.

Well, in that case this document shouldn't be being advanced.

This document has support in tsvwg (otherwise it would not have been
> adopted as wg document) and I also don't think there is anything in the
> draft that contradicts any work in the QUIC group.
>

Well, I think what you're hearing is that people think that it is badly
aligned with the consensus of other parts of the IETF.

-Ekr

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 05 Nov 2019 20:19:22 +0000

On 05/11/2019, 19:58, Eric Rescorla wrote:
>
>
> On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hi Christian,
>
>     On 04.11.19, 18:46, "Gorry Fairhurst" <[email-masked]
>     [MK] The purpose of this draft is exactly to find and document
>     consensus in the transport area and in the IETF. I don't think any
>     individual at this points knows what the consensus actually is. 
>
>
>     This document has support in tsvwg (otherwise it would not have
>     been adopted as wg document) and I also don't think there is
>     anything in the draft that contradicts any work in the QUIC group.
>
>
> Well, I think what you're hearing is that people think that it is 
> badly aligned with the consensus of other parts of the IETF.
>
> -Ekr

Than ks Ekr, but of course, I don't agree on your thoughts. Which is why 
this needs to be carefully considered.

Gorry

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 5 Nov 2019 20:34:47 +0000

See below.

> Am 05.11.2019 um 21:19 schrieb Gorry Fairhurst <[email-masked]>:
> 
>> On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>    Hi Christian,
>> 
>> Well, I think what you're hearing is that people think that it is badly aligned with the consensus of other parts of the IETF.

What I’m hearing is that 2-3 people think this is not aligned but don’t actually say why exactly they think that while there are a bunch of people supporting this document ( throughout the whole wg process).

Mirja

>> 
>> -Ekr
> 
> Than ks Ekr, but of course, I don't agree on your thoughts. Which is why this needs to be carefully considered.
> 
> Gorry
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Nov 2019 12:44:59 -0800

On Tue, Nov 5, 2019 at 12:34 PM Mirja Kuehlewind <
[email-masked]> wrote:

> What I’m hearing is that 2-3 people think this is not aligned but don’t
> actually say why exactly they think that

I wrote a fairly long note about it, I can understand that you don't agree,
but I don't really think "don't exactly say why they think that" is a fair
characterization.

while there are a bunch of people supporting this document ( throughout the
> whole wg process).

Well, it's often the case that a WG has internal support for something, but
then when it gets brought to the wider IETF community, it turns out that
there isn't IETF-wide consensus. I'll leave it to the Chairs and ADs to
determine if that's the case here.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Nov 2019 13:04:01 -0800

> On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> 
> What I’m hearing is that 2-3 people think this is not aligned but don’t actually say why exactly they think that

That’s not what we’re saying. We gave reasons. 

Joe

---

From: David Schinazi <[email-masked]>
Date: Tue, 5 Nov 2019 14:10:10 -0800

I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This
document discourages transport header encryption and publishing it could
harm future protocol development.

David

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Nov 2019 15:09:59 +1100

I just read this document.  tl;dr, I agree with David, but I'd like to provide rationale in long-form.

The introductory material is largely quite good.  Though I found it to be a little long-winded and a bit repetitious, the thesis it sets up is an oft-repeated theme of recent discussion: encryption has these benefits, but increased deployment of encryption affects certain existing practices.  Add text on ossification.  In the abstract, that's all non-controversial.  The risk that this is a repetition of RFC8404 is tempered by the prospect that this document might include a more detailed analysis of transport-level mechanisms.

However, the remainder of the document says something different.  In reading Ekr's review here, I thought that might be through implication, but I found that it was far more direct.  There is an assumption throughout that the listed practices are privileged and therefore deserving of protection.  No attempt is made to acknowledge that some of these practices are can be harmful in various ways.  No recognition is given to the possibility that involving endpoints might offer alternative methods toward the same ends.  This is perhaps exemplified in the conclusion, which states:

> An increased pace of evolution therefore needs to be accompanied by methods that can be successfully deployed and used across operational networks.

And:

> Protocols that change their transport header format (wire image) or their behaviour (e.g., algorithms that are needed to classify and characterise the protocol), will require new network tooling to be developed to catch-up with each change.  

The use of "needs" and "will" in these statements is emblematic of the theme that carries throughout this conclusion and - to a lesser extent - the preceding sections: the document clearly states that these goals are important and stresses the importance of finding replacements.  For instance, I don't think it is appropriate for an on-path box to reset a flow that doesn't conform to some ideal (S3.2.4).  If I were to state the requirement for a network operator it would be that it be possible to identify and isolate sources of traffic that are consuming disproportionate amounts of resources.  That might avoid any implication that the network operator be able to measure goodput (S3.1.2), for instance.

End-to-middle and middle-to-end signaling is something this organization has repeatedly attempted to tackle.  It's a hard problem.  Success has been patchy.  Though we might debate relative success, successful signals are few in number.  This document contains a direct and specific plea.

It is possible that this problem could be addressed by adding water until this skew is sufficiently diluted.  Sadly, the homeopathic approach we took with RFC 8404 failed.  The IETF ended up publishing an RFC in the absence of consensus.  I don't see that tactic being any more effective in this case.  The catalogue of techniques here is somewhat interesting, even if it is now outdated as Bernard suggests.  A document with the right framing might work, but that would omit any conclusion other than the one that says that these techniques are approaching extinction.  Though that might be a shame in some ways - the loss of the ability to conduct research in some ways is a loss - those are the facts on the ground.

As this is a document that intends to represent consensus, I have to oppose publication on the grounds that it includes an ask I disagree with.  I assert that it would be better to concentrate on building those signals, even if it is one hard-earned bit at a time.  For instance, let's see how ECN and spin work out in QUIC.

On Wed, Nov 6, 2019, at 09:10, David Schinazi wrote:
> document discourages transport header encryption and publishing it 
> could harm future protocol development.
> 
> David
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 6 Nov 2019 07:14:20 +0000

Hi David,

This document is not intended to discourage header encryption but to make sure that operational considerations are taken into account when exactly design new protocols that should have header encryption (as well as payload encryption). If you think this document discourages header encryption, we need to fix that. Would be helpful if you could indicate to the authors where you think this is the case.

Mirja

> Am 05.11.2019 um 23:10 schrieb David Schinazi <[email-masked]>:
> 
> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This document discourages transport header encryption and publishing it could harm future protocol development.
> 
> David
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 6 Nov 2019 07:32:05 +0000

Hi Martin,

Thanks for your more elaborated review. I don’t think there was an intention in the document to say that „listed practices are privileged and therefore deserving of protection“ but I can see how you could read it this way. I think the intention was to rather not make a judgement if these practices are „good“ or „bad“ because the assumption was that it would be even harder to find consensus on that but I agree that the document could at least explicitly state that these practices are not endorsed and not all of them are seen as worth supporting in future or any way desirable.

However I still think it is important to document current practices and spell out implication that changes in the Transport Layer can have.  I also agree that the document got a bit redundant in the mean time and some of the „could“ and „might“ might actually go too far beyond the goal of documentation. 

The document was initially not intent to talk about potential solutions or future approaches to address desired implications that have been identified. However there was quite a bit of feedback that the document should go one step further. We could reconsider this approach but I actually think the document does a good job listing potential option to move forward. I hope this document can provide a common basis for understanding problems and therefore design work the ietf might do in future in this space. However the goal right now is really documentation and not making design decisions. 

Mirja

> Am 06.11.2019 um 05:10 schrieb Martin Thomson <[email-masked]>:
>

---

From: Frode Kileng <[email-masked]>
Date: Wed, 6 Nov 2019 10:13:14 +0100

Being involved in discussions in operator communities wrt. "implications 
of encryption" for  years, the following statement from Martin 
summarizes why I also do not support publication of this draft:

On 06/11/2019 05:09, Martin Thomson wrote:
> There is an assumption throughout that the listed practices are privileged and therefore deserving of protection.  No attempt is made to acknowledge that some of these practices are can be harmful in various ways.  No recognition is given to the possibility that involving endpoints might offer alternative methods toward the same ends.

To this list I wold also add a lack of qualification of a perceived 
usefulness and some quantification of how common the practices are.

frodek

---

From: Colin Perkins <[email-masked]>
Date: Wed, 6 Nov 2019 09:58:39 +0000

> On 6 Nov 2019, at 07:32, Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
> 
> Hi Martin,
> 

It certainly wasn’t my intent with this draft to say that all these practices should be kept; rather to stimulate the discussion about what should be preserved, what it’s necessary to find alternatives for; etc. If this doesn’t come across clearly in the draft. we should fix it. 

> The document was initially not intent to talk about potential solutions or future approaches to address desired implications that have been identified. However there was quite a bit of feedback tha…

Exactly.
Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 6 Nov 2019 10:11:31 +0000

David Schinazi <[email-masked]> writes:

>document discourages transport header encryption and publishing it could harm
>future protocol development.

More than any other comment, this one seems to sum up the real opposition to
publication of this document:

  This document conflicts with my political agenda, so it cannot be allowed to
  be published.

It's a well-written discussion of issues that need to be taken into account
when considering header encryption.  Taking the "lalalalala-I'm-not-listening-
lalalala" approach won't make these issues go away, it just means that they'll
come and bite implementers and deployers of header-encryption protocols
because the document that would have discussed them in order to allow them to
be addressed at the design stage before they became a problem was suppressed.

May I instead rephrase the above objection slightly to:

  I also support publication of draft-ietf-tsvwg-transport-encrypt.  This
  document points out real issues that need to be taken into consideration
  when encrypting headers, and not publishing it will harm future protocol
  development.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Nov 2019 16:23:17 +0000

Hiya,

On 06/11/2019 10:11, Peter Gutmann wrote:
> when considering header encryption.

FWIW, I don't agree that this is (yet) sufficiently well
written. I generally agree with Martin T's criticism of
the way things are described.

In addition, the document is missing any real description
of the harmful ways in which cleartext headers are being
(ab)used today. I believe I raised this point on draft-05,
and the authors' response was that it'd be too hard to
include that. (IIRC for sorta understandable reasons that
I mostly forget;-)

From my POV, that means that the text (not the authors,
the text) is biased against encrypting headers as it has
to end up having loads of text about why encrypting is
perceived as bad by some and almost no text on why not
encrypting is perceived as bad by some.

I do think the text is fixable, but suspect getting that
done will require a lot of work, given the precedent of
RFC8404. I'm unconvinced that is the best way for those
who choose to be involved to spend their IETF cycles.

Cheers,
S.

PS: I did skim the version before last, but haven't read
the latest. I do plan to do so sometime, so I might have
other comments too later on.

---

From: David Schinazi <[email-masked]>
Date: Wed, 6 Nov 2019 09:52:33 -0800

Hi Mirja,

Perhaps I misunderstood the document. The draft makes a lists
of issues that arise when you encrypt transport headers, then
concludes with a call to action to take these issues into
consideration. In your reading, what is the desired outcome of
this document? As a protocol designer, what do you expect me
to do differently when I design my next protocol after reading this
document? The tone seems to imply that I should leave some
headers unencrypted in order "to ensure network operators,
researchers and other stakeholders have appropriate tools to
manage their networks". If this is not the intent of this draft, then
what is it? What exact outcome or we hoping for?

Thanks,
David

On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind <
[email-masked]> wrote:

> Hi David,
>
> This document is not intended to discourage header encryption but to make
> sure that operational considerations are taken into account when exactly
> design new protocols that should have header encryption (as well as payload
> encryption). If you think this document discourages header encryption, we
> need to fix that. Would be helpful if you could indicate to the authors
> where you think this is the case.
>
> Mirja
>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 07 Nov 2019 13:14:15 +1100

On Wed, Nov 6, 2019, at 20:58, Colin Perkins wrote:
> It certainly wasn’t my intent with this draft to say that all these 
> practices should be kept; rather to stimulate the discussion about what 
> should be preserved, what it’s necessary to find alternatives for; etc. 
> If this doesn’t come across clearly in the draft. we should fix it.

Thanks Colin,

I didn't start with that expectation and the introduction does a fine job of setting this out.  However the draft makes some very strong statements in the conclusion and - in a few places - the body that leave very little room for interpretation.

I'm happy to help identify specific cases, but it seemed to be fairly consistent throughout.  For the bulk of the document, perhaps the right thing to do is take another pass with a critical eye.  I don't know what to do about the conclusions section though.

I just want to say that while I appreciate the effort taken to document techniques, I'm not entirely convinced that it is the only way forward.  Discussion of existing practice can distract from the underlying needs.

To take the example of capacity planning, I had a great conversation about 18 months ago with Lee Howard about what that might look like in the presence of more opaque data flows between endpoints.  I don't think that we reached a specific conclusion, but it was refreshing to talk about the actual problem and not get bogged down in the detail of specific techniques.  Though the discussion touched on many existing and potential methods, our focus never left the important question of what the goals were and how there might be some shared interest in achieving that goal.

Being able to focus on the underlying requirements like that can be hard, but my sense is that this is where we'll need to reach before anything meaningful will happen.  I have to confess, despite enduring the spin bit debate, I find the fact that I have still trouble articulating exactly what requirements that mechanism addresses to be concerning.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 7 Nov 2019 06:51:02 +0000

Stephen Farrell <[email-masked]> writes:

>In addition, the document is missing any real description of the harmful ways
>in which cleartext headers are being (ab)used today.

That's actually something that's missing in general, not specifically in this
document.  Header encryption seems to be taken as an article of faith, we must
do this because it's something we must do, and yet from long experience with
the two protocols that do header encryption (or at least protection), IPsec
and SSH, for the former all it's produced is endless and ongoing headaches for
devices that need to forward/route/manage IPsec traffic, and for the latter
all it's produced is a string of security vulnerabilities.

So what's the sound technical - not religious - argument for header
encryption?  Calling it "abuse" is a purely subjective statement, one person's
abuse is another's essential functionality.  One big example of this DNS
manipulation to implement captive portals, which the DNSSEC folks I've talked
to regard as anathema but without which maybe 90% [figure totally invented] of
public WiFi won't work.  So to the DNSSEC fans it's abuse, to pretty much
everyone else except a few DNSSEC fans it's fine because they want public WiFi
to work for them.

In particular for header encryption there have been at least two dozen papers
published, and many commercial products created, that bypass encryption to do
fairly extensive traffic analysis *of encrypted traffic*, encrypted headers or
no.  So on the one hand we've got real-world experience with two protocols
that do header encryption/protection which has yielded endless problems
(IPsec) and security vulns (SSH), and on the other hand we've got what seems
to be a faith-based belief in something that numerous academic papers have
shown doesn't provide the service it claims to.

Where's the technical argument for header encryption, backed by actual
research showing that it's effective, and that the benefits outweigh the
disadvantages?

Peter.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 7 Nov 2019 08:16:01 -0800

> shown doesn't provide the service it claims to.
Peter,

The problems of protocol ossification and middleboxes meddling in E2E
protocols has been discussed at length in IETF in various contexts.
This is a real problem. It is well known that encryption of as much as
the packet as possible is one mitigation to present protocol
ossification. For instance, this was exactly the rationale in QUIC to
encrypt the whole transport layer.

On the other hand, the draft provides most anecdotal information that
plaintext headers are useful. For instance, there's a lot of
discussion about network operations. It is conceivable that this
unencrypted headers might help network operators, but then that raises
some obvious questions. Do all operators look into transport layer? Do
all network operator require the same information from the transport
layer header? If they do, what is the EXACT set of transport layer
information they need? Do they all support the same transport layer
protocols? What if we start using a new transport layer protocol from
hosts, are we out of luck because that protocol is not on the
"approved list"?

If there were answers to such questions then real requirements both on
the host side and network side could be articulated and there might be
a basis for a meaningful discussion, but in lieu of that all we are
left with is vague guidance for the transport layer protocol designer
that they should consider how middleboxes _might_ to meddle in the
protocol.

Tom

---

From: Colin Perkins <[email-masked]>
Date: Thu, 7 Nov 2019 19:10:03 +0000

David,

I don’t know what Mirja thinks is the desired outcome, but my intent – as an author of the draft – is that you think about the issues raised and how they relate to your protocol, then make an informed decision about what parts of the headers to protect and what parts it might make sense to expose.

And, to be explicit, if you think about the issues discussed in the draft and then decide to encrypt all the transport layer headers, that’s fine by me. 

Colin

> On 6 Nov 2019, at 17:52, David Schinazi <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind <mirja.kuehlewind@ericsson..com <mailto:[email-masked]>> wrote:
> Hi David,
> 
> Am 05.11.2019 um 23:10 schrieb David Schinazi <[email-masked] <mailto:[email-masked]>>:
> 
>> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind <mirja.kuehlewind=[email-masked] <mailto:[email-masked]>> wrote:
>> > 

-- 
Colin Perkins
https://csperkins.org/

---

From: David Schinazi <[email-masked]>
Date: Thu, 7 Nov 2019 11:24:02 -0800

Hi Colin,

Thanks for the clarification. If the intent is to get protocol developers
to think, that's always a good thing. However, I think the tone of the
document does not match this intent. I realize that this is purely
subjective, but upon reading it I really had the impression that this
document suggests that the downsides of encrypting transport
headers outweigh the benefits. Perhaps the document should
instead aim for a middle-of-the-road approach. For example, the
document could expand the mention of QUIC into a case study: the
draft could explain how QUIC considered these issues and made
the informed decision to encrypt its transport headers.

David

On Thu, Nov 7, 2019 at 11:10 AM Colin Perkins <[email-masked]> wrote:

> David,
>
> I don’t know what Mirja thinks is the desired outcome, but my intent – as
> an author of the draft – is that you think about the issues raised and how
> they relate to your protocol, then make an informed decision about what
> parts of the headers to protect and what parts it might make sense to
> expose.
>
> And, to be explicit, if you think about the issues discussed in the draft
> and then decide to encrypt all the transport layer headers, *that’s fine
> by me. *
>
> Colin
>
>
> mirja.kuehlewind@ericsson..com <[email-masked]>> wrote:
>
>> Hi David,
>>
>>> > What I’m hearing is that 2-3 people think this is not aligned but
>>> don’t actually say why exactly they think that
>>>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Nov 2019 12:05:58 -0800

Martin said:

"To take the example of capacity planning, I had a great conversation about
18 months ago with Lee Howard about what that might look like in the
presence of more opaque data flows between endpoints.  I don't think that
we reached a specific conclusion, but it was refreshing to talk about the
actual problem and not get bogged down in the detail of specific
techniques.  Though the discussion touched on many existing and potential
methods, our focus never left the important question of what the goals were
and how there might be some shared interest in achieving that goal."

[BA] Indeed, it would be very useful for there to be an IETF document that
covered the manageability problem (including capacity planning) from a
variety of perspectives, including that of the endpoints and application
service providers.  Unfortunately, draft-ietf-quic-manageability is not
(yet) that document.

On Wed, Nov 6, 2019 at 6:16 PM Martin Thomson <[email-masked]> wrote:

> I didn't start with that expectation and the introduction does a fine job
> of setting this out.  However the draft makes some very strong statements
> in the conclusion and - in a few places - the body that leave very little
> room for interpretation.
>
> I'm happy to help identify specific cases, but it seemed to be fairly
> consistent throughout.  For the bulk of the document, perhaps the right
> thing to do is take another pass with a critical eye.  I don't know what to
> do about the conclusions section though.
>
> I just want to say that while I appreciate the effort taken to document
> techniques, I'm not entirely convinced that it is the only way forward.
> Discussion of existing practice can distract from the underlying needs.
>
> To take the example of capacity planning, I had a great conversation about
> 18 months ago with Lee Howard about what that might look like in the
> presence of more opaque data flows between endpoints.  I don't think that
> we reached a specific conclusion, but it was refreshing to talk about the
> actual problem and not get bogged down in the detail of specific
> techniques.  Though the discussion touched on many existing and potential
> methods, our focus never left the important question of what the goals were
> and how there might be some shared interest in achieving that goal.
>
> Being able to focus on the underlying requirements like that can be hard,
> but my sense is that this is where we'll need to reach before anything
> meaningful will happen.  I have to confess, despite enduring the spin bit
> debate, I find the fact that I have still trouble articulating exactly what
> requirements that mechanism addresses to be concerning.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 08 Nov 2019 09:12:05 +0000

On 07/11/2019, 19:10, Colin Perkins wrote:
> David,
>
> I don’t know what Mirja thinks is the desired outcome, but my intent – 
> as an author of the draft – is that you think about the issues raised 
> and how they relate to your protocol, then make an informed decision 
> about what parts of the headers to protect and what parts it might 
> make sense to expose.
>
> And, to be explicit, if you think about the issues discussed in the 
> draft and then decide to encrypt all the transport layer headers, 
> /that’s fine by me. /
>
> Colin
>
+1.

My personal view is that this seeks to provide input to those developing 
IETF specifications to describe how they have considered PM, and, if the 
attack is relevant to the work to be published, be able to justify 
related design decisions.

Gorry

>
>> On 6 Nov 2019, at 17:52, David Schinazi <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Mirja,
>>
>> On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind 
>> <mirja.kuehlewind@ericsson..com 
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi David,
>>
>>     This document is not intended to discourage header encryption but
>>     to make sure that operational considerations are taken into
>>     account when exactly design new protocols that should have header
>>     encryption (as well as payload encryption). If you think this
>>     document discourages header encryption, we need to fix that.
>>     Would be helpful if you could indicate to the authors where you
>>     think this is the case.
>>
>>     Mirja
>>
>>
>>     Am 05.11.2019 um 23:10 schrieb David Schinazi
>>     <[email-masked] <mailto:[email-masked]>>:
>>
>>>     I also oppose publication of draft-ietf-tsvwg-transport-encrypt.
>>>     This document discourages transport header encryption and
>>>     publishing it could harm future protocol development.
>>>
>>>     David
>>>
>>>         > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind
>>>         <mirja.kuehlewind=[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>         >
>>>         > What I’m hearing is that 2-3 people think this is not
>>>         aligned but don’t actually say why exactly they think that
>>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Nov 2019 12:27:47 -0500

I have a slightly different perspective on this. To me, a Web Server is
just another type of middle-box.

Specifically, it is a middle-box between the content provider and the
content-consumer. And those are the ends I wish to achieve end-to-end
security between.

Transport security is useful but that has been our only hammer for 25 years
now. Data in transport is a solved problem, the breaches occur in data at
rest. And as a famous Snowden breach slide shows: 'TLS added and removed
here'.

This is not to say anyone made an error in design. What was possible when
we were looking at this in 1993 was considerably less than what we can do
today. We were using export grade encryption for a start. And we could
barely use one layer of encryption. And so we adopted TLS as a Golidlocks
solution that provided most of the network layer security we need and most
of the application layer security.

I think we need to change our perspective somewhat because we need TLS and
Data at rest security (DARS) and we do need certain types of metering. But
in the network, not in the inter-network.

Alice uploads content to Carol's Cloud, Bob reads it with his browser.
There are three (potentially) separate networks here.

Alice's local network
Bob's local network
Carol's local network

Alice, Bob and Carol might all see the need to do certain types of
monitoring. But the principle of least privilege should apply in each case.
Carol's need to monitor her network is strictly limited to Carol's needs.

In addition, we have the inter-network which as Einer Stefferud used to
remind us, isn't a network, it is a network of networks. And so the
communication graph is:

Alice <-> Internet <-> Carol <-> Internet <-> Bob

And that matters, because the primary concerns we are addressing in TLS are
the ones raised by that 'Internet' hop. The advantage of IPSEC over TLS is
that it allows us a much more closely targeted solution that locks down the
Internet hop without affecting anything else. The disadvantages of IPSEC...

So what I see happening at the moment is QUIC/TLS morphing into what IPSEC
was originally trying to do. Which is fine except that as EKR is point out,
this is compromising us at the upper layers. Which is where Shen and SHTTP
were originally intended to work.

I am actually planning to use three layers of encryption for Mesh services

Transport - (TLS) to provide traffic analysis resistance.
Presentation - (DARE) to authenticate client/server interactions
Data - To protect data at rest

The concern that Transport Layer Security inevitably creates is that any
scheme which provides any traction against traffic analysis is going to
make monitoring difficult because it is traffic analysis.

In summary, there is no way to square this circle because what
distinguishes traffic analysis attack from monitoring is intent and
machines can't tell the intent. And so if people want to expose information
at the lower layers, they are going to need to think about additional
layers of crypto being added at the top.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 9 Nov 2019 12:40:59 -0500

People have asked me for an infographic to illustrate my point. Well I only
have text here.

Encryption is like a too-short blanket when you are trying to sleep in bed.
If you pull it up over your shoulders, you get cold toes. If you cover your
feet, the rest of you gets cold. There is nowhere that you can put that
blanket that is going to keep all of you warm and they only come in one
size. So what you need is more blankets.

If we only have one layer of encryption for headers and payload, it is all
or nothing. If the payload is encrypted inside the encrypted transport, we
can strip off the transport encryption with much less risk.

And that is part of what we will be discussing in the MATHMESH BOF in the
first session of the first day in Singapore.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Nov 2019 07:06:58 +0000

>protocols has been discussed at length in IETF in various contexts.

I'm aware of RFC 3234, which was written seventeen years ago and focuses on
middleboxes messing with application-layer data, as well as farcical stuff
like RFC 3424, of the same vintage, but it's mostly complaining rather than
actual rigorous analysis, and often seems to be based on opposition to
middleboxes as an article of faith, notoriously manifested in IPsec's "NAT is
bad, therefore we will make sure IPsec breaks NAT, because NAT is bad", which
has caused endless headaches for pretty much anyone who's ever had to work
with IPsec ever since.

In particular for this case, since the discussion is about header encryption
and not middleboxes in general, I'm not aware of any rigorous analysis of its
purported benefits, or even a clear statement of its purported benefits,
something like "here is a definition of the service that header encryption
provides, here is a real-world study showing that it provides this and
demonstrating that it can't be readily defeated".  Contrast this with the two
dozen plus studies that look at the analysis of encrypted traffic despite the
encryption, an example being (just one picked at random) "Identifying HTTPS-
Protected Netflix Videos in Real-Time", Andrew Reed and Michael Kranch,
Proceedings of the 7th Conference on Data and Application Security and Privacy
(CODASPY'17), March 2017, p.361.

So when people complain that the draft doesn't say enough about all the Good
Things header encryption provides, I would respond that it does, it's cited
all of the available literature on the benefits of header encryption, and all
of the studies showing that it's effective, in Appendix B.

The draft is actually quite restrained in this regard, as I mentioned in my
previous message the two notable examples of header encryption/protection
deployed at scale into the real world, IPsec and SSH, have both been a
disaster (for functionality, IPsec, and security, SSH), but it very politely
omits mention of this.

Peter.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 12 Nov 2019 09:42:37 -0500

On Tue, Nov 12, 2019 at 2:07 AM Peter Gutmann <[email-masked]>
wrote:

> After work on RFC8404, I do think having such research conducted would be
beneficial.  This was one of the aims of the proposed group SMART.  If
there is interest in conducting this work (writing research drafts, etc.),
please let me or Kirsty Paine know.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Nov 2019 07:54:58 -0800

On Wed, Nov 6, 2019 at 10:51 PM Peter Gutmann <[email-masked]>
wrote:

> .  So on the one hand we've got real-world experience with two protocols

On the other hand, we also have WebRTC which tunnels SCTP over DTLS (thus
encrypting the SCTP headers) and that seems to work out fine.

As far as "the services it claims to", the primary argument for encrypting
headers in QUIC (and the handshake metadata in TLS 1.3) is to prevent
middleboxes interfering with protocol evolution. We certainly have evidence
of a number of cass where that has happened, though I don't think we yet
have strong evidence that encrypting more of the metadata prevents this
from happening because we mostly just started doing so. OTOH, I'm not aware
of any academic papers showing the contrary.

-Ekr

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Nov 2019 08:18:44 -0800

Peter,

https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_huitema.pdf
describes with some detail how encryption of the transport layer is
beneficial to resolve the tussel that results in protocol
ossification.

>From that document: "We know that embedding encryption and
authentication inside the transport protocol provides a powerful API
to applications, and also enables sophisticated handling of path
redundancy and mobility... We know all that because we have tried it
before.", also "The effect of middle-boxes on transport protocols is
obvious."

Tom

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 Nov 2019 03:10:41 +0000

Tom Herbert <[email-masked]> writes:

>beneficial to resolve the tussel that results in protocol ossification.

I'd always assumed the push for header encryption was due to some vague
handwaving about privacy or something else that's never really been made
clear, but from the above document it looks like the motivation is purely
ideological ("If we want to break that ossification, we have to do something
drastic", "we can score at least a partial win for end-to-end connectivity",
"application developers win a similar tussle", "reverses the balance of power
between end-to-end and middle-boxes"), which indicates that it'll end up as a
repeat of the IPsec debacle ("Let's make sure IPsec breaks NAT, because IPsec
will be bigger than NAT and so NAT will have to go away").

Someone really needs to do a proper design document and threat model for this
if it's that unclear what the goals of header protection are - is it for some
sort of privacy thing, an ideological move because people don't like
middleboxes, something to thwart the lizard people, to impress Jodie Foster,
or what?

Might I suggest that the IETF suspend any further push towards header
encryption until someone can figure out:

a. Why we're doing this.

b. What its intended goals and effects are.

c. Whether those goals will be met in practice.

d. Whether it will work when deployed in the real world.

At the moment it looks like (a) is at best very unclear and (b), (c), and (d)
are pretty much nonexistent.

Peter.