Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

Spencer Dawkins at IETF <> Thu, 27 February 2020 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA2323A0B5B for <>; Thu, 27 Feb 2020 12:25:06 -0800 (PST)
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 kqlMg0gr7Bzi for <>; Thu, 27 Feb 2020 12:25:04 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCF703A0B60 for <>; Thu, 27 Feb 2020 12:25:03 -0800 (PST)
Received: by with SMTP id 7so363928lfz.11 for <>; Thu, 27 Feb 2020 12:25:03 -0800 (PST)
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=hNtdKQ/oyZUBY0mx3MLCtHZu7SBxMTfczbDd0eSS34c=; b=tDQ97wkOL/gx3wX4H1N+vDFAOslI9IVj4xtaxb3ujz+j4VUQ5/ujeLtb7wXUCIPpcb U4qzyqBjLSGQyzDxyejXQ4gRgM8VaZkJ0aWBmtShs5RX1+BFfhYwKPz3ylG4ahab/HYm Y34XMAn1dXtkfGqUZ19haIOAEXnh5SvyIR7Pxyfg0PfCLT8bUuBh4Exisx/uWmwFoPlD vm58gYAIQFgXMDYAiqZfVaNxGT2DRsHK64dJcPHQubPiqhEqKfTCH4P/Thmeqho0SntL SnBRJ/9ignzJt2CO8CSQfpf2Zl1cRGDkuJkAzIkWVm6/EBqkhI5R1HU6nzl3uHtvllHe QErw==
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=hNtdKQ/oyZUBY0mx3MLCtHZu7SBxMTfczbDd0eSS34c=; b=N/eckn5g2mGWscR1z0N3+rc2MSlLs8zMS3ABvEmJQIAfINmQFA383jmN9Tk+HVc/YB 0DTX/qotDO4xGTyL4IdzaFRcTNtdBGEZfSYX26Cft6hJZdxWc6mI8gH9uTLoMo/3ZLRc 0rYsy8FwcWqOyrdafUjC7fXGxX6H9VR+uQSEiB+YD7LpPdrfBvcoRhdN1am5SOZyzvPd X9yVKO+dnKB7mcq5Yvkl3ggcn2xE/OIB4DkZu5ZXlQWGc/29hYd7V6FkI32H5P7HhHEA Oye1qlA16sTe7WxM51mTj76VNuU8grbPRxHhyPKF3cIevdOCPA8bWDECLybif9gU1Vyp 8iFA==
X-Gm-Message-State: ANhLgQ05EqsNmiz/O8JueaqpvkeY5trktL3vxHa1DrEGISv688SJLxuN vgwveVwuQpRIZzKRiG8BCz7Z/YHkOMwOdif+z7sq+ZhsUBSgdQ==
X-Google-Smtp-Source: ADFU+vvArT90QpcUXoInSpO6O7Nxj7wwr9M01vlfInU35XCdeRUQgAe1cb8z3TbCvcNO0GYVYZBweQXkQox8qhF2FFU=
X-Received: by 2002:a19:6a07:: with SMTP id u7mr618133lfu.152.1582835101953; Thu, 27 Feb 2020 12:25:01 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Thu, 27 Feb 2020 14:24:35 -0600
Message-ID: <>
To: Gorry Fairhurst <>
Cc: David Schinazi <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000fd718a059f9483d8"
Archived-At: <>
Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
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: Thu, 27 Feb 2020 20:25:07 -0000

Speaking as a non-area director (so, I don't have a hat to remove) ...

On Thu, Feb 27, 2020 at 1:18 PM Gorry Fairhurst <>

> We discussed the scope a lot at the start, and the advice I received was
> that this is not the document to tell people about what they have to do.
> I think the decisions about whether to encrypt all transport fields or
> some or none isn't something I saw huge consensus upon. I did see many
> strong arguments, but what I heard often depended on which working group
> was speaking and the background of people involved. Had I asked a different
> question, e.g. do you think Privacy is important I would have got a
> different answer (we do have a BCP that notes that).
> The AD advice I recall at the time we asked to work on this, correct me
> Spencer if I am wrong, was to not attempt a BCP until the WG could first
> publish an informational document. This is that document. The purpose then,
> as I see, is to examine where we have arrived. Had we had a document like
> this, other discussions such as how to manage QUIC, whether PLUS could be
> useful, etc could have been more informed and focussed.
I believe I was the AD who gave this advice, and Gorry is recounting that
story the way I remember it.

>From my perspective, we had just been through a great deal of kerfluffling
with MARNEW(1), SPUD(2), ACCORD(3), PLUS(4), and "Effects of Pervasive
Encryption on Operators"(5), all of which had various levels of
food-flinging, and all of which had various levels of assertions about
whether operators needed to manage transport protocols, with little
agreement on ground truths about what was, and was not, possible to manage
when looking at existing transport protocols.

I wasn't seeing anything that led me to expect that to change before the
earth fell into the sun, and the volume level was increasing (watching
Meetecho for the PLUS BOF would drive anyone to drink, even today). So I
encouraged Gorry to focus on ground truths, so that we would be able to
actually have discussions about what might go into a BCP for protocol
designers (as David reasonably points out, that would be great), and/or a
BCP for network operators.

One can debate whether I did the right thing (but that wasn't appealed, and
I wasn't recalled). I'd defer to the current ADs (both now and after IETF
107) on what to do next, but I thought it would be useful to provide
background on how TSVWG got here.

Best of luck to Magnus, Mirja, and Martin, of course. And you don't HAVE to
have a name that starts with the letter "M" to stand as a nominee for TSV
AD this coming Nomcom cycle :-)