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

From: "Black, David" <[email-masked]>
Date: Tue, 9 Jun 2020 01:41:40 +0000

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-masked]<mailto:[email-masked]>) - 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:

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

  1.  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-masked]<mailto:[email-masked]> list, although purely

editorial comments may be sent directly to the authors.  Please cc: the

WG chairs at [email-masked]<mailto:[email-masked]>  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)

---

From: Paul Vixie <[email-masked]>
Date: Tue, 09 Jun 2020 17:45:33 +0000

On Tuesday, 9 June 2020 01:41:40 UTC Black, David wrote:
> list ([email-masked]<mailto:[email-masked]>) - 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

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 12 Jun 2020 12:03:39 -0400

The term “let’s encrypt” is used countless times as a generic reference 
in the IETF, other SDOs and the marketplace.  It is about as generic a 
term as exists today.  However, it appear that the ISRG is attempting to 
claim the term as their own in the marketplace through the US Patent and 
Trademark Office coupled with complaints about alleged infringements.

https://www.theregister.com/2020/06/10/lets_encrypt_trademark_complaints/ 
<https://protect-us.mimecast.com/s/_4BYC4xvlEHB0WJBhOdEh-?domain=theregister.com>

This is preposterous and an abuse of the trademark and standards systems 
to create a marketplace monopoly.

If you use the USPTO online system, you can see the full history.
http://tmsearch.uspto.gov/ 
<https://protect-us.mimecast.com/s/gvtDC5ywmJHZjK0ZiOIqF0?domain=tmsearch.uspto.gov>
Click on "Basic Word Mark Search" and enter “Let’s Encrypt”

This was originally Comodo’s mark filed on 16 Oct 2015 and abandoned 25 
June 2016.  Thirteen days later, ISRG which exists as a tax-exempt, 
non-profit corporation for advancing "educational" objectives, filed for 
the mark.

A considerable number of entities have used the term Let's Encrypt in 
the marketplace for all kinds of purposes, including as a political 
movement.  Google Search finds about 6,840,00 of them going back almost 
20 years.

It is found 447 times in the IETF alone for advancing all manner of 
activities without ever disclosing a trademark assertion.

For the ISRG to threaten some other company for using the term “Let’s 
Encrypt” with the arguments at the end of The Register article is beyond 
inappropriate.  The term is generic and used by countless others in the 
marketplace.

Lastly and most significantly, the actual Let’s Encrypt word mark – 
Serial Number 88828174 was just filed on 10 March 2020, asserting first 
use in commerce on 24 Feb 2020, and is just being published for 
Opposition on 7 July 2020.

Interested parties should file a USPTO opposition.  Those representing 
the ISRG minimally owe the IETF Trust the courtesy of filing an IPR notice.

LET'S OPPOSE

--tony

---

From: Kyle Rose <[email-masked]>
Date: Wed, 17 Jun 2020 11:21:32 -0400

On Mon, Jun 8, 2020 at 9:41 PM Black, David <[email-masked]> wrote:

> https://datatracker.ietf.org/doc/draft-ietf-tsDo we have machines near IAD
> that Asgard can use vwg-transport-encrypt/
> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/>
>
I support requesting publication of this draft as an informational RFC.

There's no reason a draft aimed exclusively at identifying,
contextualizing, and offering high-level mitigations for a set of related
technical problems (in this case, the operational problems exacerbated by
transport header encryption) needs to incorporate advocacy of any kind. It
is very clear from other publications and from on-going work that the
consensus of the IETF is in favor of measures to combat pervasive
surveillance and to limit protocol ossification. The purpose of *this*
document seems to be to end the pretense that there is no resulting
tradeoff or that by ignoring operational issues related to transport header
encryption they'll go away on their own. That said, even then it does not
in any way advocate against transport encryption, and is circumspect in its
proposals for measures to improve diagnostic visibility.

Kyle

---

From: "Roni Even" <[email-masked]>
Date: Thu, 18 Jun 2020 20:37:48 +0300

Hi,

I support the publication of this draft. In my view the concerns were
answered and it reflects the view that there are consequences when
encryption the transport headers but does not claim that they should not  be
encrypted. 

As section 1 mentions it also  explains the text in RFC7258 section 2 about
when PM is useful and as such I think that the document must be published.

Roni Even

From: tsvwg [mailto:[email-masked]] On Behalf Of Black, David
Sent: Tuesday, June 09, 2020 4:42 AM
To: [email-masked]
Cc: int-area; IETF SAAG
Subject: [tsvwg] 3rd WGLC (limited-scope):
draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

This email announces a limited-scope 3rd TSVWG Working Group Last Call
(WGLC) on: 

list ([email-masked]) - please don't remove that list address if/when

those concerns:

clearly understood.

2.	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
<https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-transport-encrypt-12&url
2=draft-ietf-tsvwg-transport-encrypt-15>
&url2=draft-ietf-tsvwg-transport-encrypt-15

Comments should be sent to the [email-masked] list, although purely

WG chairs at [email-masked]  if you would like the chairs to

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 Jun 2020 10:43:23 -0700

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-masked]> wrote:
> been cc:’d to the SAAG and INT-AREA lists courtesy of the breadth of
>
> list ([email-masked]) – please don’t remove that list address if/when
>
> Whether or not to proceed with a request for RFC publication
>
> strong views that this draft should not be published –  those
> Review of changes made since the -12 version of the draft that
> David and Wes (TSVWG Co-Chairs – Gorry is recused as a draft author)
>
>
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 18 Jun 2020 18:08:22 +0000

+1 on Kyle's remarks[1], and well-put.

IMO, this doc seems useful and should move forward as informational.

While I do also think a BCP would be great, since we're not there
yet an informational RFC articulating the points this one does is a
very welcome step forward and much better than nothing, IMO.

-Jake

PS: Also +1 to Paul Vixie's suggestion that the objections should
ideally be phrased as a pull request.  There's perhaps room for
some editorial improvements, but as it stands it's pretty readable,
and has some crucial information about the new challenges that
transport header encryption introduces to existing operational
practices.

So my +1 on objections-as-pull-request is because I'm not
understanding the tone or balance problems that were raised.  I
don't see what kinds of edits would address them outside of "stop
acknowledging that there are new challenges raised by transport
header encryption" or "add 14 pages duplicating info in the
referenced RFCs about why encryption is good".  Both of these seem
counterproductive to me, so absent a more specific set of productive
suggestions (ones that don't lose information about the new
operational challenges that are introduced by transport header
encryption), I am against stalling publication of this doc as an
RFC based on the objections raised so far.

[1] Kyle's remarks:
https://mailarchive.ietf.org/arch/msg/tsvwg/0UNJbELTHMw7xjV9SIXoavADK6g/

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 19 Jun 2020 09:20:55 +0100

Thanks Tom,

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

> which can reveal the OS and version which can be useful information

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jun 2020 17:59:38 -0700

> is welcome and encouraged to ensure that their concerns are

Well, I'll try again, but I'm not sure that I can do better than
I have before.

For reasons that are laid out in RFC 7258, the trend in protocol
design in IETF is towards encrypting more and more. The last two
transport protocols that were designed and widely deployed (SCTP over
DTLS and QUIC) both encrypt the vast majority of the protocol
metadata. This document advertises itself as "considerations"
for design of such protocols:

   The transport protocols developed for the Internet are used across a
   wide range of paths across network segments with many different
   regulatory, commercial, and engineering considerations.  This
   document considers some of the costs and changes to network
   management and research that are implied by widespread use of
   transport protocols that encrypt their transport header information.
   It reviews the implications of developing transport protocols that
   use end-to-end encryption to provide confidentiality of their
   transport layer headers, and considers the effect of such changes on
   transport protocol design, transport protocol evolution, and network
   operations.  It also considers some anticipated implications on
   application evolution.  This provides considerations relating to the
   design of transport protocols and features where the transport
   protocol encrypts some or all of their header information.

However, as I said above, the new transport protocols that are
actually being designed already feature metadata encryption and as far
as I can tell, there is no prospective protocol new transport protocol
design project for which these issues might be live. In that context,
it's hard not to read this document with its long litany of practices
which are impacted by metadata encryption as a critique of the
decisions by SCTP/DTLS and QUIC to encrypt most of the metadata.

This impression is reinforced by the description of the actual
practices themselves, which focuses almost entirely on practices
which appear to be benignly motivated (e.g., performance monitoring,
troubleshooting, etc.) However, we also know that metadata is widely
used for practices in which the network operator is adversarial
to the user, for instance:

- Blocking traffic based on TCP port, IP address, SNI, etc.

- Performance-based traffic class discrimination

- Monitoring the user's behavior via indicia like the ones above
  or via traffic analysis (see [0])

Yes, I understand that the authors explicitly disclaim judgement on
these practices, and the document does briefly touch on the general
idea, though the "concerns...have been voiced" tends to minimize those
concerns [1] but the selection of practices to focus on is extremely
telling. Focusing on the downsides of encryption for (at least
arguably well-meaning) network players while mostly ignoring the large
class of non-benign behaviors which encryption is intended to protect
against has the effect of overemphasizing the costs of encryption to
those players and minimizing the benefits to the endpoints whom it is
intended to protect.

To be maximally clear: I don't object to this document existing
and I don't think that the opinions implicit in it are ones that
should not be expressed. I merely don't think that it should be
published as an IETF Consensus document.

-Ekr

[0]
https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5
[1]    Another motivation stems from increased concerns about privacy and
      surveillance.  Users value the ability to protect their identity
      and location, and defend against analysis of the traffic.
      Revelations about the use of pervasive surveillance [RFC7624]
      have, to some extent, eroded trust in the service offered by
      network operators and have led to an increased use of encryption
      to avoid unwanted eavesdropping on communications.  Concerns have
      also been voiced about the addition of information to packets by
      third parties to provide analytics, customisation, advertising,
      cross-site tracking of users, to bill the customer, or to
      selectively allow or block content.  Whatever the reasons, the
      IETF is designing protocols that include transport header
      encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement
      the already widespread payload encryption, and to further limit
      exposure of transport metadata to the network.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 30 Jun 2020 05:49:34 +0000

I believe this document signals a wrong message to the wider Internet community. I agree that it should not be published as a consensus document.

I understand that some people are unhappy about encrypting more meta-data. This prevents them from doing things they used to do in the past, some of which they should have never done in the first place.
Improving the protection of meta-data is important and well supported by a large number of activities in the IETF (the notable exception being CoAP+OSCORE).

Ciao
Hannes

From: saag <[email-masked]> On Behalf Of Eric Rescorla
Sent: Tuesday, June 30, 2020 3:00 AM
To: Black, David <[email-masked]>
Cc: int-area <[email-masked]>; [email-masked]; IETF SAAG <[email-masked]>
Subject: Re: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

-Ekr

[0] https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.