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 <[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
