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

[Eric Rescorla <[e-mail]>]

On Thu, Nov 7, 2019 at 9:09 AM Tommy Pauly <tpauly=
[e-mail]> 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
> - 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
>

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

-Ekr

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