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

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> 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".

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


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