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

[Gorry Fairhurst <[e-mail]>]

Thanks Tom,

On 18/06/2020 18:43, Tom Herbert wrote:
> 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."

The intention is indeed to document things (as an INFO RFC) and indeed 
for this draft not to provide actionable guidance for protocol developers.

If the IETF can't document the concerns/motivations for using this 
information, then I would suggest we shouldn't be providing guidelines 
for use at the Internet or transport layers. However, my hope is that we 
can agree what exists/existed, and that we can facilitate a way forward.

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

The public wifi example is one case that I expect many to agree upon. 
There are clearly ways that information can be/is being mis-used. The 
expectation could perhaps be differnent for a company's enterprise 
gateway to their network supplier, or a subscription to a cellular 
provider., etc. This document doesn't try to explore use-cases either, 
which may well be a part of understanding a way forward.

Gorry

> Tom
>
> On Mon, Jun 8, 2020 at 6:42 PM Black, David <[e-mail]> 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]) – 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 [e-mail] list, although purely
>>
>> editorial comments may be sent directly to the authors.  Please cc: the
>>
>> WG chairs at [e-mail]  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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area