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

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 <David.Black@dell.com> 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 (tsvwg@ietf.org) – 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 tsvwg@ietf.org list, although purely
>
> editorial comments may be sent directly to the authors.  Please cc: the
>
> WG chairs at tsvwg-chairs@ietf.org  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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area