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

Paul Vixie <> Wed, 10 June 2020 19:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DF543A0FB2 for <>; Wed, 10 Jun 2020 12:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wm3NrlqwGlrl for <>; Wed, 10 Jun 2020 12:00:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 224F63A1082 for <>; Wed, 10 Jun 2020 12:00:29 -0700 (PDT)
Received: from linux-9daj.localnet ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by (Postfix) with ESMTPSA id 08C90B07D1; Wed, 10 Jun 2020 19:00:26 +0000 (UTC)
From: Paul Vixie <>
To: "" <>
Cc: Mike Bishop <>
Date: Wed, 10 Jun 2020 19:00:24 +0000
Message-ID: <1676009.p4SS4celVB@linux-9daj>
Organization: none
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [tsvwg] 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: Wed, 10 Jun 2020 19:00:50 -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:
>       A network operator can observe the headers of transport protocols
>       layered above UDP to understand if the datagram flows comply with
>       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.