I am neutral on this draft. While the authors certainly have done a good job at improving the draft over time and it is a lot more balanced between the arguments to encrypt or not encrypt transport, there really isn't much in terms of actionable guidance for protocol developers. It seems the best that can be said is that transport protocol designers should consider the issues. The pertinent statement from the draft:
"The decision about which transport headers fields are made observable offers trade-offs around header confidentiality versus header observability (including non-encrypted, but authenticated, header fields) for network operations and management, and the implications for ossification and user privacy [Measurement]. Different parties will view the relative importance of these differently." This is true, and the last sentence is telling. Users are one of those parties, and in fact probably the most important party at the end of the day. If a tradeoff is made that exposes some information to the network with the knowledge that the exposure provides more benefits than potential harm to a user then that might be an acceptable tradeoff. However such a tradeoff could only be correctly made at runtime based on assessment of the risks and benefits for the particular circumstances. This really can't be a design decision burned into the transport protocol. For instance, I, as a user, might be willing to expose a lot of information about my packets to my local carrier if I have a contractual agreement that describes security and privacy provided and exactly what benefits I get from the provider for volunteering the information. However if I'm connected to some public random WIFI, I really want the absolute minimum level of information exposed. Generally, we don't know a priori what transport information a particular network might "need", nor that there aren't malicious parties in the path intent on abusing exposed information. So, fundamentally, transport information exposure is discretionary and should be controlled by the user and the only reasonable security default is that no information is exposed (I think this could be normative requirements if the draft offers any). There is also the possibility that the transport protocol developer may expose fields that are considered innocuous to make visible. This is risky since there is precedent that information considered safe turned out to reveal sensitive information (case in point is analysis of TCP options which can reveal the OS and version which can be useful information for a DOS attack). Tom On Mon, Jun 8, 2020 at 6:42 PM Black, David <[email protected]> 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 ([email protected]) – please don’t remove that list address if/when > > replying with WGLC comments. > > > > This 3rd WGLC will run through the end of the day on Monday, June 29, > > 2 weeks before the draft submission cutoff for IETF 108. > > > > This 3rd WGLC is limited to the following two topics: > > > > Whether or not to proceed with a request for RFC publication > > of the draft. The decision on whether or not to proceed will > > be based on rough consensus of the WG, see RFC 7282. > During the 2nd WGLC, Eric Rescorla and David Schinazi expressed > strong views that this draft should not be published – those > concerns have not been resolved and are carried forward to > > this WGLC. This email message was an attempt to summarize > > those concerns: > > https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/ > > Further explanation from both Eric Rescorla and David Schinazi > > is welcome and encouraged to ensure that their concerns are > > clearly understood. > > > > Review of changes made since the -12 version of the draft that > was the subject of the second WGLC (e.g., whether or not they > suffice to resolve concerns raised during that WGLC, other > than overall objections to publishing this draft as an RFC): > > https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-transport-encrypt-12&url2=draft-ietf-tsvwg-transport-encrypt-15 > > > > Comments should be sent to the [email protected] list, although purely > > editorial comments may be sent directly to the authors. Please cc: the > > WG chairs at [email protected] if you would like the chairs to > > track such editorial comments as part of the WGLC process. > > > > No IPR disclosures have been submitted directly on this draft. > > > > Thanks, > > David and Wes (TSVWG Co-Chairs – Gorry is recused as a draft author) > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
