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

Spencer Dawkins at IETF <> Tue, 30 June 2020 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEF023A0B49 for <>; Tue, 30 Jun 2020 09:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0_qS5FvUv154 for <>; Tue, 30 Jun 2020 09:30:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B89EA3A0A7B for <>; Tue, 30 Jun 2020 09:30:29 -0700 (PDT)
Received: by with SMTP id u25so11793548lfm.1 for <>; Tue, 30 Jun 2020 09:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Db6fyRn2aqynE7JatyaJYSkccGAyoQhLkkdjPgQWSzw=; b=k48dDNOPUUshDoQwZX1oM0oi+MyvTRmiDrGDVI/54nMloZ7t4O4C91tKa2fM28ffhe xdb7UoD88a837VGYPvRFWttYfvIoAW7ttxnEghhssdzh1q6hpEAuKGvXDR+W7mnlyqEJ IEF9pIihS8D0HmIORbu88GKmQemRVT1pNYezm682UImW8nWmoGXJTrYyhoCrIOgR7guk Ck7O1rM62oFynSEMXjiX58wq2oUtjTUQzN1ey+Srm5YThQtPgIiUIyy9d2Jt99yHKbNO vNmD843PbOhE2vv1Fu4zLKOfNDpJP/j3fbt/CyTX5LKnobejan02g3d5yGNpDGvFiwqY gVfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Db6fyRn2aqynE7JatyaJYSkccGAyoQhLkkdjPgQWSzw=; b=dCrMtsEGLUCoSno0dE02YpT5K3SqhvlCV2TDTKq+tVUitLqA9pOWUzkcsfJ6RylNtv FVrXhEPdgIy4N87m5tbH7K58C7R6ImIVlK4+HbH0WsxLA3bhDMdMcVZzKHmzAUT22Yn0 3oOw7c7vVwtgAla767qEI/QRyQHCA0jjtk45XSh2Bcw5UIO+f+RSpyuTlzUE1vmTKoal 8qKSdOfksL6jc44A0Hd5aivGYOUiTK23I3Ey4VuKLMcaJQiwIS4byO4eC3hvrvlLjX8E Y4TAOrX5WLMB0CFs+vcnLOJl8Q1Lg40b1Zfs8tMGGTznnDbmBUhJg1pkoNazFtzKf5mz clxA==
X-Gm-Message-State: AOAM533/F7+zZJtsbweeG95pUT+2tafSszhKvx5mAINRXtrm/WB2c8XS QC2rR9juPLHC06lyciHApjuq0D2CiiqFMsl+cc04RnL3
X-Google-Smtp-Source: ABdhPJyYc7AQcsi2oedvxbprjzusd8PFmld7Yo4UU21EKLmLYfHKuYILW2PyFR+usgwOcWmFskGLuhuPBRUVFTvX7Oo=
X-Received: by 2002:ac2:558f:: with SMTP id v15mr12504462lfg.187.1593534627860; Tue, 30 Jun 2020 09:30:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Tue, 30 Jun 2020 11:30:00 -0500
Message-ID: <>
To: Martin Thomson <>
Cc: tsvwg <>
Content-Type: multipart/alternative; boundary="0000000000006e548005a94fb1df"
Archived-At: <>
Subject: Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jun 2020 16:30:32 -0000

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

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 <> wrote:

> On Tue, Jun 9, 2020, at 11:41, Black, David wrote:
> >  1. Whether or not to proceed with a request for RFC publication
> > 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.

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


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.

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

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.


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

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