Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

[Paul Vixie <[e-mail]>]

On Tuesday, 9 June 2020 01:41:40 UTC Black, David wrote:
> This email announces a limited-scope 3rd TSVWG Working Group Last Call
> (WGLC) on:
> 
>     Considerations around Transport Header Confidentiality, Network
>      Operations, and the Evolution of Internet Transport Protocols
>                  draft-ietf-tsvwg-transport-encrypt-15
> 
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
> 
> This draft is intended to become an Informational RFC.  This WGLC has
> been cc:'d to the SAAG and INT-AREA lists courtesy of the breadth of
> interest in this draft, but WGLC discussion will take place on the TSVWG
> list ([e-mail]<mailto:[e-mail]>) - please don't remove that list
> address if/when replying with WGLC comments.

the goals of "prevention of network ossification" are incompatible with 
layering exits such as a router using non-routing header information to guide 
its operations. this isn't a new constraint collision -- consider OSPF ECMP 
which needs to examine the TCP or UDP header to find a 5-tuple to hash upon.

as this draft is informational, objections of the form "it says something that 
is untrue or at least confrontational" or "it lacks something essential" are 
in scope and the answer should be "send a pull request". whereas objections of 
the form shown in the e-mail summary (archival) thread you referenced:

(https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/)
> I would like to see this useful content in a BCP document once we have
> enough information to actually recommend something.

are out of scope because this document isn't making any recommendations, and

(ibid)
> 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.

are regressive, leading back to the result of "send a pull request" since the 
consensus being sought isn't about a recommendation but rather a depiction of 
known considerations. unknown considerations should not concern us, since 
those always exist and cannot be addressed until they make themselves known. 
known considerations which are missing, incomplete, or misleading in the text 
as drafted, should be fixed.

i have two objections, both of which are inoperable at this time due to the 
limited scope of this WGLC. (you're asking for pass/fail, and the time for me 
to have suggested these changes has passed.)

first, section 7.2 could do some real good by enumerating local operating 
system and local network policy as reasons why a transport protocol should 
have low-entropy markers. on many endpoints and within many networks, 
uncharacterized traffic will be dropped. the advance of DoH has caused and 
will continue to cause broader adoption of required explicit proxies to 
prevent uncooperative insiders from bypassing DNS policy controls. QUIC is 
going to cause UDP to become a privileged operation, denied except for 
classifiable traffic, to prevent similar bypasses.

a brief examination of these deployment obstacles to PM-resistant transport 
deployment would help inform the manageability draft, and may even motivate a 
secure proxy discovery protocol similar to what the ADD WG is working on for 
secure RDNS discovery. it's clear that DHCP in its current form will never be 
used to communicate any endpoint parameter which has security value. a 
transport protocol which permits an on-path device to authentically deny an 
unclassifiable flow will be deployed more quickly and more widely, and so a 
mention of these tensions in section 7.2 might accelerate darwinism here.

second, the absence of signaling within the IP and IP6 headers to drive the 
advancement of congestion management is a form of ossification, and should be 
blamed here. the needs of L4S or SCE or similar should not have a bearing on 
QUIC or for that matter even on TCP. so, when discussing anti-ossification as 
a goal, this document could highlight that previous ossification has created 
many of the tensions the document will go on to describe in detail. this bit 
of history won't be known by most readers, and could provoke cognitive 
dissonance if left untreated.

given the inoperable (because: late) nature of my objections, i support 
publication of this draft. thank you for giving us a chance to comment.

vixie