Subject: [tsvwg] Suggestions on draft-ietf-tsvwg-transport-encrypt-09

From: Tommy Pauly <[email-masked]>
Date: Thu, 07 Nov 2019 09:08:25 -0800

Hello TSVWG,

I've just read through the latest update to the Transport Header Encryption Considerations draft, draft-ietf-tsvwg-transport-encrypt-09. First off, the changes to the introduction, etc, do make things clearer. Thanks to the authors for those changes!

In light of the discussion going back and forth on the intent and appropriateness of the draft, I do indeed agree with the points being raised that the tone of the draft is a bit inconsistent: reading through the introduction, I get the impression that this document will explain to the reader the new way things will work in the world of encrypting our transports. And indeed, section 2.1 does give some good transport-layer rationale about ossification. However, much of the rest of the document can indeed be read as pointing out a laundry list of problems (particularly section 6) with using encryption. I do not believe that the intent of this document is to discourage encryption (and I would have concerns if it were), but I can also understand how some readers can get that impression.

However, I do believe that a document in this space—a statement on and guide for transport protocols that are encrypted—is valuable. I think that the document does need to be edited to perform this role, but it can serve a positive role in clarifying the benefits and necessity of encryption.

Protocols like QUIC that provide transport header encryption are indeed a huge benefit to the development of transport protocols, since they allow us to keep doing work on changing the transport without being caught up by the ossification of the network. Not only is encryption of headers important for privacy and security, but it has become a necessary method to allow work on transport protocols to evolve. If this message can be carried throughout the document, I think the message will be clearer. Yes, the passive signals that previously allowed middleboxes to infer loss patterns will not be visible—but those same signals are the ones that prevent the transport from changing to improve (and also allows anyone else to fingerprint the user!). If the justification for having network signaling is that it is useful to allow the network to optimize and improve traffic performance and reliability, then the advocates for these optimizations should also take into account the fact that protocols that encrypt headers (like QUIC) are the places where we can successfully deploy performance enhancements like 0-RTT connection setup and connection migration, in ways that cleartext solutions like TFO and MPTCP stumble.

As has been pointed out already, much of the operational considerations are already described by RFC 8404. Some of the discussion of these operational considerations in the TSV document could be reduced to point to that RFC, rather than needing to reiterate.

It may be good to, as a community, re-look at the conclusions section as the place to rework the tone. The choice it presents at the end is, as far as I can tell, the main concern that is being highlighted: that there should be some choice between encrypting transport headers and not encrypting them, depending on what you want the network to be able to do. Practically, I don't see that being the choice before protocol designers. What we see in the case of the Spin Bit in QUIC is that we are adding new mechanisms that are explicit signals, which are arguably outside of the domain of the original notion of transport headers, since the endpoints themselves consume an encrypted form of the information that acts as their true authority at the transport layer. The document brings up IOAM signaling and other mechanisms for measurement, which are also explicit signaling outside of the transport. This seems to be the more obvious conclusion. Of course, clients may not opt into these measurement mechanisms, but that is the choice and evolution that needs to play out. Perhaps the conclusion could lay out something similar to this logic:
- Transport headers are being encrypted, because it has become necessary to preserve privacy and allow for the evolution of transport protocols
- Signals that middleboxes passively read will not be available anymore, which makes certain functionality harder
- If clients want to get the functionality that middleboxes provide while using encrypted transports, they will need to come up with explicit signaling mechanisms

Best,
Tommy

-----

Also, two typos in the document:

Section 1:

... nis a technical ...

Should be:

... is a technical ...

Section 2.3:

... regulators to explore teh ...

Should be:

... regulators to explore the ...

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Nov 2019 09:23:04 -0800

On Thu, Nov 7, 2019 at 9:09 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> As has been pointed out already, much of the operational considerations
> are already described by RFC 8404. Some of the discussion of these
> operational considerations in the TSV document could be reduced to point to
> that RFC, rather than needing to reiterate.
>
> It may be good to, as a community, re-look at the conclusions section as
> the place to rework the tone. The choice it presents at the end is, as far
> as I can tell, the main concern that is being highlighted: that there
> should be some choice between encrypting transport headers and not
> encrypting them, depending on what you want the network to be able to do.
> Practically, I don't see that being the choice before protocol designers.
> What we see in the case of the Spin Bit in QUIC is that we are adding new
> mechanisms that are explicit signals, which are arguably outside of the
> domain of the original notion of transport headers, since the endpoints
> themselves consume an encrypted form of the information that acts as their
> true authority at the transport layer. The document brings up IOAM
> signaling and other mechanisms for measurement, which are also explicit
> signaling outside of the transport. This seems to be the more obvious
> conclusion. Of course, clients may not opt into these measurement
> mechanisms, but that is the choice and evolution that needs to play out.
> Perhaps the conclusion could lay out something similar to this logic:
> - Transport headers are being encrypted, because it has become necessary
> to preserve privacy and allow for the evolution of transport protocols
> - If clients want to get the functionality that middleboxes provide while
> using encrypted transports, they will need to come up with explicit
> signaling mechanisms
>

Isn't this point already well reflected in RFC 8558?

-Ekr

Tommy
> .... nis a technical ...
> .... is a technical ...
> .... regulators to explore teh ...
>
> Should be:
>
> .... regulators to explore the ...
>
>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 07 Nov 2019 09:29:45 -0800

> On Nov 7, 2019, at 9:23 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> On Thu, Nov 7, 2019 at 9:09 AM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:

Yes, I think that the conclusions are indeed the same, and it is important to come to that point. I don't think that makes this document just a duplicate of RFC 8558, necessarily. Having this longer document to go into the explanation of why this conclusion is necessary may be useful, since the message may reach a different audience in this form.

Thanks,
Tommy
> ..... nis a technical ...
> 
> Should be:
> 
> ..... is a technical ...
> 
> Section 2.3:
> 
> ..... regulators to explore teh ...
> 
> Should be:
> 
> ..... regulators to explore the ...
>