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

[Gorry Fairhurst <[e-mail]>]

Thanks Joe for your comments.

See our editorial notes below, but please have a look at our revised ID.

New text introduced, this was a mistake in revising the abstract, we 
think it is in scope to discuss the benefits/drawbacks of integrity 
protection also: 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

Para rephrased.  We do agree with this statement and have stated this 
publically when presenting this draft -- 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 agree with your disagreement -- 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

This is true, I'd love to find text we can all agree upon that says how 
we should do things in the future: but I am also aware of a wide range 
of intense feelings and operational practice in our community ... from 
those who have reacted to privacy concerns, some countries push for net 
neutrality, others on a digital divide with concerns over cost; etc etc. 
I think an important outcome of the document is to capture what is being 
done, wording has been updated -- 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)

It states: "Using encryption to provide confidentiality of the transport 
layer brings some well-known privacy and security benefits and can 
therefore help reduce ossification of the transport layer.", we also 
added text -- 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.

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

As far as I know TCP-AO-ENC is still an individual submission, I don't 
know of operational use. -- 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)

Added reference to TCPcrypt: draft-ietf-tcpinc-tcpcryp -- sec 3 omits 
TCPcrypt too (not sure where to put it because I haven’t cared to track 
how it has (d)evolved).

Changed the wording introducing transport to "The transport layer 
provides end-to-end interactions between endpoints (processes) using an 
Internet path." -- 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).

This was not an intention -- 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).

Best wishes,

Colin and Gorry

On 11/05/2018, 05:20, Joe Touch wrote:
> 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)
>
> ----
>
>