Re: [tsvwg] New Version Notification for draft-fairhurst-tsvwg-transport-encrypt-07.txt

[Joe Touch <[e-mail]>]

Hi, Gorry, et al.,

I disagree with the tone and focus of this document.

It appears to give many reasons why hiding transport info from on-path observers is bad - bad for the network, bad for operators, and bad for everyone.

It reads like an Orwellian propaganda brochure on how Big Brother is only here to help - won’t you leave the cameras on?

The doc fails to recognize:
	- the fact that encryption (via tunneling, esp) is already undermining a lot of this sort of “help” 
	- the fact that users can - and should - find a lot of what passes for “help” quite a bit creepy
	- the fact that transport protocols were never intended to have any meaning anywhere but the endpoints
		and that, in fact, that’s the only place where they do have meaning anyway

If this doc goes forward, I sincerely hope there will be a more balanced presentation of the CONS of the kind of on-path snooping of traffic that this document largely presents as beneficial.

Joe

———

Some details follow:

- the title and abstract focus on transport header confidentiality; this begs the need for sections 3.1, 3.2, and parts of 3.4 - which have nothing to do with *transport header* confidentiality
	- the doc reports in other ways to address transport encryption in general; that’s a much larger issue to include, with entirely different implications

- the doc speaks of ossification as if it is only harmful; that same ossification provides the stability on which other upper layer protocols often rely, so having a “stable” (ossified) protocol could be considered an advantage too (beyond merely allowing in-network devices to predict their location)
	- I disagree that encryption of transport headers would prevent ossification; they could similarly be ossified by being the only ones supported using encryption at the endpoints

- the doc focuses on the impact of transport header encryption on a number of “features” that have emerged, but fails to address whether those “features” are desirable (i.e., just because we CAN do certain things, and HAVE DONE certain things, is independent of whether we should continue to design protocols to support those things)

- the intro fails to address the valid privacy motivations for obscuring transport information, esp. given transport protocols are themselves meaningful ONLY at the endpoints
	e.g., I could easily modify two hosts to exchange packets that look like UDP but are actually TCP
	this is akin to port renumbering at the endpoints
	fundamentally, in the Internet, transport headers have meaning ONLY at the two endpoints engaging in a given communication, so we really are “living on borrowed time” to assume that in-network devices can - or should - be able to interpret them at all, even when they appear not to be encrypted

- I do NOT agree of nearly anything in section 2.1, especially as it is then used to justify the remainder of section 2
	this entire section reads a lot like “the government needs to track your every move so we can build better roads for you”; it’s quite creepy.

- section 3 omits discussions of encrypted tunnels (IPsec or otherwise), all of which obscure access to transport headers

- sec 3.2 (if retained, and I hope it is not), should include tcp-ao-enc (yes, still a draft, but relevant to the discussion if retained)

- sec 3 omits TCPcrypt too (not sure where to put it because I haven’t cared to track how it has (d)evolved).

- not sure I agree that the transport layer is the first end-to-end interaction across the Internet; the same is true for the IP layer (esp, e.g., IPv6 Destination Options, among other things).

- finally, this doc seems oblivious to the reality that encryption is coming, like it or not - esp across the backbone, and that this has been the case for a while now (with VPNs)

----