Subject: [tsvwg] 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: <[email-masked]>
Date: Tue, 9 Jun 2020 09:15:23 +0000

Hi David, all,

I support this document to be published as an RFC.

The authors already addressed my comments in an early version of the document. I do have some minor nits that I will share with the authors offline.

Cheers,
Med

De : saag [mailto:[email-masked]] De la part de Black, David
Envoyé : mardi 9 juin 2020 03:42
À : [email-masked]
Cc : int-area; IETF SAAG
Objet : [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

those concerns:

clearly understood.

Thanks,

---

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: Mike Bishop <[email-masked]>
Date: Wed, 10 Jun 2020 15:45:50 +0000

At a high level, I find myself agreeing with David and Ekr: this document doesn’t tell you whether to encrypt, it describes what breaks if you do.  According to the Conclusion, that is its goal.

   This document has described some current practises, and the

   implications for some stake holders, when transport layer header

   encryption is used.  It does not judge whether these practises are

   necessary, or endorse the use of any specific practise.

I was surprised, however, that it doesn’t go into equal depth about what breaks if you don’t encrypt.  While both sides of the coin are present in the document, one side is presented in considerably more detail than the other.  This document starts off fairly balanced; I found Section 2 to be an excellent discussion of the trade-offs in this space.  Section 3 turns a corner into an extensive discussion of all the things inspection of the transport headers are used for today, weighing in at 14 pages.  Interestingly, this includes at least one example of exactly the behavior that’s discussed as a problem in Section 2:

      A network operator can observe the headers of transport protocols
      layered above UDP to understand if the datagram flows comply with
      congestion control expectations.

Dropping packets which don’t comply with the operator’s “expectations” in a protocol they don’t understand is exactly why new protocols and evolution of existing protocols want to limit the ability of these devices to inspect their traffic.

Section 4.1 devotes all of one page to the reasons why protocol developers might choose to encrypt; the rest of section 4 describes various forms of integrity and confidentiality mechanisms in extant protocols.  The remainder of the document discusses alternative ways to enable the scenarios of Section 3 in the presence of encryption.

On the whole, I think this document could be suitable for publication as an Informational RFC; it provides real-world context for a trade-off that every protocol designer needs to consider carefully.  However, I don’t believe its current state reflects, in Ekr’s words, “the IETF community's view of the relative priority of these concerns.”

From: QUIC <[email-masked]> On Behalf Of Lars Eggert
Sent: Wednesday, June 10, 2020 4:08 AM
To: IETF QUIC WG <[email-masked]>
Subject: Fwd: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

FYI

Begin forwarded message:

From: "Black, David" <[email-masked]<mailto:[email-masked]>>
Subject: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
Date: June 9, 2020 at 4:41:40 GMT+3
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: int-area <[email-masked]<mailto:[email-masked]>>, IETF SAAG <[email-masked]<mailto:[email-masked]>>

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.

strong views that this draft should not be published –  those

Thanks,
David and Wes (TSVWG Co-Chairs – Gorry is recused as a draft author)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 10 Jun 2020 19:00:24 +0000

On Wednesday, 10 June 2020 15:45:50 UTC Mike Bishop wrote:
> ...
> Interestingly, this includes at least one example of exactly the behavior
> that’s discussed as a problem in Section 2:
 
>       congestion control expectations.

for managed secure networks in homes and businesses, unclassified traffic 
won't be permitted. UDP itself is a privileged protocol in those environments, 
allowed to pass through the outbound firewall only if the source or 
destination address or port or some combination. this constraint should be 
highlighted for all protocol designers. things like QUIC need a "hook".

i know that public networks might use such a hook for the opposite purpose -- 
to deny what they can recognize rather than to allow what they can recognize. 
if that risk isn't already well enough described in the IAB's PM dictates, i 
have no objection to adding references or even new text to this draft to make 
sure this document isn't accidentally misleading.

i don't agree with the restriction quoted above that it be for "congestion 
control expectations" although flow-aware rate limiting is one important 
manageability concern. for policy or legal regime reasons, a protocol which 
maximizes entropy such that there's no way to identify its flows so as to 
allow them to exit, will be less deployable and less deployed.

> Dropping packets which don’t comply with the operator’s “expectations” in a
> protocol they don’t understand is exactly why new protocols and evolution
> of existing protocols want to limit the ability of these devices to inspect
> their traffic.

while true, that's unbalanced. forget about dropping packets which don't 
comply, and consider the networks who won't forward packets unless they 
comply, and who very much want the benefits of modern encrypted protocols but 
who cannot enjoy those benefits because they cannot identify that traffic.
 
> On the whole, I think this document could be suitable for publication as an
> Informational RFC; it provides real-world context for a trade-off that
> every protocol designer needs to consider carefully.  However, I don’t
> believe its current state reflects, in Ekr’s words, “the IETF community's
> view of the relative priority of these concerns.”

the ietf community is incredibly narrow compared to the world it serves. very 
few of the people and companies whose future will be chosen for them by ietf 
work can afford the time or travel it takes to be represented. this may be an 
inconvenient truth, but it is my reason for considering whether this document 
reflects the broader view of the world's digital economy. i think it does.

-- 
Paul

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Jun 2020 15:57:17 -0500

I have opinions about this draft that I've been pretty vocal about to the
working group during the past couple of years and in the first two WGLCs,
but just to follow up on this point:

> On Wednesday, 10 June 2020 15:45:50 UTC Mike Bishop wrote:

snipped

> reflects the broader view of the world's digital economy. i think it does.

Keeping in mind that the target is publication as an Informational RFC, I
believe the governing BCP definition is still
https://tools.ietf.org/html/rfc2026#section-4.2.2, which says

4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

Does anyone think that's been updated?

If this document was targeting publication as a BCP, concerns about whether
this document reflects the consensus of the Internet community would be on
target, but it's targeting Informational, and should be evaluated with that
target in mind.

Best,

Spencer

p.s. Funny story - IESGs that EKR and I served on, among others, talked
about whether the RFC 2026 definition of Informational made sense in the
21st century, but ADs are busy, and the definition never changed. ISTM
that at a minimum, the text should say "*might* not represent an Internet
community consensus or recommendation", rather than "*does* not represent
does not represent an Internet community consensus or recommendation".

Now that we have a GENDISPATCH working group, there's actually a place that
the community can go to talk about that definition, if anyone wants to.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Jun 2020 15:52:17 -0700

> Does anyone think that's been updated?

Indeed it has:

https://tools.ietf.org/html/draft-halpern-gendispatch-consensusinformational-04

-Ekr

---

From: Joseph Touch <[email-masked]>
Date: Thu, 11 Jun 2020 15:57:08 -0700

Whoa… let’s be clear.

At this time, all we know is that there is a DRAFT proposing to change the process. That draft itself has not been published.

So it’s premature to claim that the draft represents IETF consensus yet; as such, it HAS NOT **YET** affected anything.

Joe

> On Jun 11, 2020, at 3:52 PM, Eric Rescorla <[email-masked]> wrote:
> 
> Keeping in mind that the target is publication as an Informational RFC, I believe the governing BCP definition is still https://tools.ietf.org/html/rfc2026#section-4.2.2 <https://tools.ietf.org/html/rfc2026#section-4.2.2>, which says 
> 
> 4.2.2  Informational
> 
> https://tools.ietf.org/html/draft-halpern-gendispatch-consensusinformational-04 <https://tools.ietf.org/html/draft-halpern-gendispatch-consensusinformational-04>
> 
> -Ekr

---

From: "Black, David" <[email-masked]>
Date: Thu, 11 Jun 2020 23:16:00 +0000

> Whoa… let’s be clear.

Actually, Ekr was clear ... he just left out a few crucial details ;-).

According to https://datatracker.ietf.org/doc/draft-halpern-gendispatch-consensusinformational/history/, draft-halpern-gendispatch-consensusinformational was approved by the IESG in early March and is now in AUTH48 (Authors’ final review) state at the RFC Editor.

Thanks, --David

From: tsvwg <[email-masked]> On Behalf Of Joseph Touch
Sent: Thursday, June 11, 2020 6:57 PM
To: Eric Rescorla
Cc: Mike Bishop; [email-masked]
Subject: Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

[EXTERNAL EMAIL]
Whoa… let’s be clear.

Joe

On Jun 11, 2020, at 3:52 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

Keeping in mind that the target is publication as an Informational RFC, I believe the governing BCP definition is still https://tools.ietf.org/html/rfc2026#section-4.2.2, which says

4.2.2  Informational

Indeed it has:

-Ekr

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Jun 2020 18:42:47 -0500

Hi, Ekr,

> https://tools.ietf.org/html/draft-halpern-gendispatch-consensusinformational-04

Thanks for the clue. I'm not paying close attention to process stuff these
days.

Best,

Spencer

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Jun 2020 19:57:46 -0400

On Thu, Jun 11, 2020 at 7:43 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

>>> I have opinions about this draft that I've been pretty vocal about to
>>> the working group during the past couple of years and in the first two
>>> WGLCs, but just to follow up on this point:
>>>
>>> Keeping in mind that the target is publication as an Informational RFC,
>>> I believe the governing BCP definition is still

That slipped by me too, and I am sure many more.

-- 

Best regards,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Jun 2020 18:58:39 -0500

So, backing up a bit ... since the update to RFC 2026 has been approved.

On Wed, Jun 10, 2020 at 10:46 AM Mike Bishop <[email-masked]> wrote:

> At a high level, I find myself agreeing with David and Ekr: this document
> doesn’t tell you whether to encrypt, it describes what breaks if you do.
> According to the Conclusion, that is its goal.
>
> I was surprised, however, that it doesn’t go into equal depth about what
> breaks if you *don’t* encrypt.  While both sides of the coin are present
> in the document, one side is presented in considerably more detail than the
> other.  This document starts off fairly balanced; I found Section 2 to be
> an excellent discussion of the trade-offs in this space.  Section 3 turns a
> corner into an extensive discussion of all the things inspection of the
> transport headers are used for today, weighing in at 14 pages.
> Dropping packets which don’t comply with the operator’s “expectations” in
> a protocol they don’t understand is *exactly* why new protocols and
> evolution of existing protocols want to limit the ability of these devices
> to inspect their traffic.
>
>
>
> Section 4.1 devotes all of one page to the reasons why protocol developers
> might choose to encrypt; the rest of section 4 describes various forms of
> integrity and confidentiality mechanisms in extant protocols.  The
> remainder of the document discusses alternative ways to enable the
> scenarios of Section 3 in the presence of encryption.
>

Are there reasons why protocol developers might choose to encrypt beyond
what's pointed to in the draft, including reasons included by reference to
https://tools.ietf.org/html/rfc8546, which appear in 3.1 and 3.1.1?

Is there a place that they are written down, so they could be included by
reference?

Best,

Spencer

> *From:* QUIC <[email-masked]> *On Behalf Of * Lars Eggert
> *Sent:* Wednesday, June 10, 2020 4:08 AM
> *To:* IETF QUIC WG <[email-masked]>
> *Subject:* Fwd: [tsvwg] 3rd WGLC (limited-scope):
> draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
>
>
>
> FYI
>
>
>
> Begin forwarded message:
>
>
>
> *From: *"Black, David" <[email-masked]>
>
> *Subject: [tsvwg] 3rd WGLC (limited-scope):
> draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020*
>
> *Date: *June 9, 2020 at 4:41:40 GMT+3
>
> *To: *"[email-masked]" <[email-masked]>
>
> *Cc: *int-area <[email-masked]>, IETF SAAG <[email-masked]>
>
>
>
> list ([email-masked]) – please don’t remove that list address if/when
>
> Comments should be sent to the [email-masked] list, although purely
>
> WG chairs at [email-masked]  if you would like the chairs to
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Jun 2020 19:14:48 -0700

Auth48 != published. 

Until the doc is announced as an RFC, it remains a draft. 

Joe

> On Jun 11, 2020, at 4:16 PM, Black, David <[email-masked]> wrote:
> 
> 
> > Whoa… let’s be clear.
>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 11 Jun 2020 19:27:11 -0700 (PDT)

> >> > every protocol designer needs to consider carefully.  However, I don?t
> >> > believe its current state reflects, in Ekr?s words, ?the IETF
> >> community's
> >> > view of the relative priority of these concerns.?
> >>

I have read this draft, and like what it says.  One small nit,
OBE is used all capitals, so I must assume it is an abbreviation,
perhaps Over come By Events?  But I seriously doubt it is the
most common found definition of:

	an award given in the UK for a special achievement;
	a person who has received this award (the abbreviation
	for `Officer of the Order of the British Empire') 

Regards,
Rod Grimes

-- 
Rod Grimes                                                 [email-masked]

---

From: Mike Bishop <[email-masked]>
Date: Mon, 15 Jun 2020 20:31:08 +0000

The examples that come to mind that are mostly mentioned briefly in the document:

  *   MP-TCP dealing with middleboxes
  *   TLS 1.3 dealing with middleboxes
  *   Attempts to deploy TCP Fast Open
  *   Attempts to deploy ECN
  *   Google QUIC breaking when a flag in the header was used for the first time

I’m not aware of good write-ups of the specifics, though.  I recall that David Benjamin did a good talk about the TLS 1.3 case, though I’m not coming up with the video link now.

From: Spencer Dawkins at IETF <[email-masked]>
Sent: Thursday, June 11, 2020 7:59 PM
To: Mike Bishop <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

On Wed, Jun 10, 2020 at 10:46 AM Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
At a high level, I find myself agreeing with David and Ekr: this document doesn’t tell you whether to encrypt, it describes what breaks if you do.  According to the Conclusion, that is its goal.

Are there reasons why protocol developers might choose to encrypt beyond what's pointed to in the draft, including reasons included by reference to https://tools.ietf.org/html/rfc8546, which appear in 3.1 and 3.1.1?

Is there a place that they are written down, so they could be included by reference?

Best,

Spencer

From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Lars Eggert
Sent: Wednesday, June 10, 2020 4:08 AM
To: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Fwd: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

FYI

Begin forwarded message:

Thanks,

---

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: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jun 2020 19:21:00 -0700

Ask and ye shall receive:
https://www.rfc-editor.org/info/rfc8789

On Thu, Jun 11, 2020 at 7:15 PM Joe Touch <[email-masked]> wrote:

> According to
> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-consensusinformational/history/,
> draft-halpern-gendispatch-consensusinformational was approved by the IESG
> in early March and is now in AUTH48 (Authors’ final review) state at the
> RFC Editor.
>
>
>
> Thanks, --David
>
>
>
> *From:* tsvwg <[email-masked]> *On Behalf Of * Joseph Touch
> *Sent:* Thursday, June 11, 2020 6:57 PM
> *To:* Eric Rescorla
> *Cc:* Mike Bishop; [email-masked]
> *Subject:* Re: [tsvwg] 3rd WGLC (limited-scope):
> At this time, all we know is that there is a DRAFT proposing to change the
> process. That draft itself has not been published.
>
>
>
> So it’s premature to claim that the draft represents IETF consensus yet;
> as such, it HAS NOT **YET** affected anything.
>
>
>
> Joe
>
>
>

---

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

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:
> Whether or not to proceed with a request for RFC publication
>
> Review of changes made since the -12 version of the draft that
> _______________________________________________
> 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: "Christopher Wood" <[email-masked]>
Date: Mon, 29 Jun 2020 18:35:02 -0700

On Mon, Jun 8, 2020, at 6:41 PM, Black, David wrote:
> of the draft. The decision on whether or not to proceed will be based on rough consensus of the WG, see RFC 7282.

As currently written, I'm still not sure this document is ready for publication. While many of the items in my secdir review [1] were addressed, I think the document is still somewhat misaligned with the IETF's overall view on this document. 

For example, Section 6 (on intentionally exposing information) and some of Section 7 (the impact of header encryption) seem out of phase with our general mission to "encrypt all the things." Minimally, I would expect to see some discussion of endpoint privacy here, and reasons for why an endpoint might not want to expose certain signals to the network. Section 6.3 seems to outright encourage endpoints to expose cleartext information in the name of performance. Certainly this can't be a necessary condition for performance given studies on QUIC [2] (it's not always better than TCP+TLS, though). 

In general, while I appreciate that the Conclusion narrows in on User Privacy, I would expect it to be more prominent in this document, especially one that ultimately seeks IETF consensus. As a document "about design and deployment considerations for transport protocols," I think we ought to focus more on deployment considerations for who those transport protocols actually service: the end users. I happily offer up my service in producing such text should it be desired.

Best,
Chris

[1] https://datatracker.ietf.org/doc/review-ietf-tsvwg-transport-encrypt-01-secdir-early-wood-2018-12-27/
[2] https://dl.acm.org/doi/10.1145/3131365.3131368

---

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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 30 Jun 2020 08:29:47 +0100

Thanks, see below.

> In general, while I appreciate that the Conclusion narrows in on User Privacy, I would expect it to be more prominent in this document, especially one that ultimately seeks IETF consensus. As a doc…

Your offer is appreciated. Some suggested text on these topics would be 
very welcome.

I also agree that the way section 6 finally was written would benefit 
from some privacy considerations text (and the need to protect from 
misuse of info) this could be usefully added at/after 6.3.

A few other corrections have been submitted off-list, and we would like 
to make a new revision soon.

Gorry

-- 
G. Fairhurst, School of Engineering

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 30 Jun 2020 19:36:11 +1000

On Tue, Jun 9, 2020, at 11:41, Black, David wrote:
> of the draft. 

I think that this is in many ways vastly improved over earlier versions.  Much of the language that was more directly addressing the shortcomings.

If RFC 8517 had IETF consensus and RFC 8404 had IETF consensus, then this would clearly be a good companion to those documents.  In many ways, this is a far better document.  If you were to consider this the unabridged version of Section 2 of RFC 8558, then it's a pretty good attempt at capturing uses.  Though, like Ekr, I wonder about the distinct absence of stuff that is clearly bad, because there's a lot of that too.

However, despite having quite a reasonable introduction and conclusion, the impression the document leaves is that the use of encryption is endangering the livelihoods of a great many people and that is a bad thing.  I don't think that it is possible to avoid with a document in this form.

After reading it through (again, it's quite long), I reached the conclusion that all the trappings and disclaimers don't serve their intended end, but they tend to work against it.  By so clearly addressing the whole problem in framing, but then spending the bulk of the text on one aspect of that problem, the overwhelming impression is that there is a great deal of substance to the view that use of encryption produces harms.  After all, look at all these useful things that can't be done any more.

Instead, I think it could be better to dispense with the attempt to be balanced and simply present - without attempts to motivate, frame, or justify - the practices that are employed by intermediaries.  Including a brief diversion regarding some of the bad things, realizing that any attempt to plumb the depths of that particular rathole would never end.

Of course, that makes me even more inclined to recommend following the path RFC 8517 took.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 30 Jun 2020 11:30:00 -0500

I'm only vaguely replying to Martin (and I thank him for the thoughtful
comments).

If it turns out that I sound moody below, my apologies. However, some days,
you get what I've got to give.

On Tue, Jun 30, 2020 at 4:36 AM Martin Thomson <[email-masked]> wrote:

> I think that this is in many ways vastly improved over earlier versions.
> Much of the language that was more directly addressing the shortcomings.
>
> If RFC 8517 had IETF consensus and RFC 8404 had IETF consensus, then this
> would clearly be a good companion to those documents.  In many ways, this
> is a far better document.  If you were to consider this the unabridged
> version of Section 2 of RFC 8558, then it's a pretty good attempt at
> capturing uses.  Though, like Ekr, I wonder about the distinct absence of
> stuff that is clearly bad, because there's a lot of that too.
>
> However, despite having quite a reasonable introduction and conclusion,
> the impression the document leaves is that the use of encryption is
> endangering the livelihoods of a great many people and that is a bad
> thing.  I don't think that it is possible to avoid with a document in this
> form.
>
> After reading it through (again, it's quite long), I reached the
> conclusion that all the trappings and disclaimers don't serve their
> intended end, but they tend to work against it.  By so clearly addressing
> the whole problem in framing, but then spending the bulk of the text on one
> aspect of that problem, the overwhelming impression is that there is a
> great deal of substance to the view that use of encryption produces harms.
> After all, look at all these useful things that can't be done any more.
>
> Instead, I think it could be better to dispense with the attempt to be
> balanced and simply present - without attempts to motivate, frame, or
> justify - the practices that are employed by intermediaries.  Including a
> brief diversion regarding some of the bad things, realizing that any
> attempt to plumb the depths of that particular rathole would never end.
>

I will say this, so Gorry doesn't have to - I remember pretty vividly that
early versions of this draft were pretty much that. Several years ago.
Before it was "improved".

<rant>

I haven't been following this draft revision-by-revision since stepping
down as TSV AD (not my job, dude), but let me ask my question this way.

The QUIC charter contains roughly the same test as it did when the working
group was first approved:

Current practices for network management of transport protocols
include the ability to apply access control lists (ACLs), hashing of
flows for equal-cost multipath routing (ECMP), directional signaling
of flows, signaling of flow setup and teardown, and the ability to
export information about flows for accounting purposes.

Note that the above is not an exhaustive list of network management
practices - that list was pounded out by the 2016 TSV, OPS, and SEC ADs
before the charter was approved, and was written to respond to Discusses.

The QUIC
protocol need not be defined to enable each of these abilities, or
enable them in the same way as they are enabled by TCP when used
with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, reflecting the tensions
described in RFC 7258.

ISTM that recent discussions in this (3rd!) WGLC have been headed toward
"everything is moving to QUIC and similar transport protocols, and is going
to work the way QUIC works, and all this stuff is going to be encrypted,
greased, and whatever else, except for a spin bit, so why do we still need
this draft?"

QUIC has the applicability and manageability statements scheduled for
delivery in (checks charter) July 2020, which starts next week. Do we think
that those drafts, in something like their current form, tell operators
what they need to know about network management of encrypted transport
protocols, that draft-ietf-tsvwg-transport-encrypt-15 is trying to tell
them?

If Yes, please carry on. If Not Yet, maybe that's relevant for discussions
about draft-ietf-tsvwg-transport-encrypt-15.

I'll stop there, but not because I've run out of opinions.

</rant>

Do the right thing, of course.

Spencer, who (I'm not kidding) told Warren Kumari that he and I should
co-author a draft BCP on Network Management practices for QUIC, and start
with a -00 that contains only this text:

"It sucks to be an operator trying to manage a network carrying QUIC"

and see if that generated more PRs, or achieved IETF consensus in that
form.