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

Joseph Touch <> Wed, 01 July 2020 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A9153A0FC0; Wed, 1 Jul 2020 08:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rvj5Tu7ISY4x; Wed, 1 Jul 2020 08:10:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B1743A0F70; Wed, 1 Jul 2020 08:10:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z2b1oJfMZWhqgpJOAvbJBlITwqpk0odidCMacY9No7w=; b=lM9D8tUghIcJXvx3qSPwNYMHc Nh9llgtNc6TSY2L1xSg91AOQuGqrBJYokzt88L7Cusv80/S5D1yj9i9N7Wy4jcOpxIeHa36sx6iui e2/fmRQgzdSIUGJn6OhkOCuE9B0VvPF8DOk9G/a+UW5/ibqBV3HbFl3qVb9fKCBHeBGMBhV5Z3NsE tEa656DDJ2l2pyJ7Xkd4S6/h2PDtqRqZ4IGXsVnK386nAJ4b795Qg00BKJQwq+wOUUnY+1zcb7rYB 3pRkTOotO8sYUgantflHnEeuYYT4KM5L1osZ9BynecppNne8J6a0e6v42Aii9Jv7PpyHiNb6Rti1+ CkY1F3wnw==;
Received: from ([]:63836 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1jqeNK-000Vug-8H; Wed, 01 Jul 2020 11:10:19 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_4FA01920-6117-43F8-A62F-5ACC54665501"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Joseph Touch <>
In-Reply-To: <FRAPR01MB04015215AF32FC06B8A7184BD16C0@FRAPR01MB0401.DEUPRD01.PROD.OUTLOOK.DE>
Date: Wed, 1 Jul 2020 08:10:13 -0700
Message-Id: <>
References: <> <> <> <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <> <> <FRAPR01MB04015215AF32FC06B8A7184BD16C0@FRAPR01MB0401.DEUPRD01.PROD.OUTLOOK.DE>
X-Mailer: Apple Mail (2.3608.
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tsvwg] [Int-area] [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: Wed, 01 Jul 2020 15:10:30 -0000


Although it’s understandable to describe “what operators do”, the IETF isn’t a news service. We typically summarize these behaviors to take a position on them.

The draft provides a good description of the tradeoff between the privacy rights of endpoints and the rights of operators and the impact of both on protocol design on that tradeoff.

What I seem to be seeing is increasing “rough consensus” that the summary position should be closer to endpoint privacy than in the current form.

Although I don’t feel strongly that the text absolutely needs revision in that direction, I would oppose changes to relax or shift in the other direct.


> On Jul 1, 2020, at 7:11 AM, wrote:
> +1
> Thanks, Kyle!
> Kind regards
> Dirk
> From: Int-area < <>> On Behalf Of Kyle Rose
> Sent: Mittwoch, 1. Juli 2020 15:57
> To: Hannes Tschofenig < <>>
> Cc: int-area < <>>; <>; IETF SAAG < <>>
> Subject: Re: [Int-area] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
> On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig < <>> wrote:
> I noticed this in various IETF discussions and so I will describe it in the abstract.
> A group of people propose an idea. Those who do not like the idea are then asked to convince the original contributors that their idea is not sound or contribute text so make it look nicer. 
> Not only is this requiring me to spend my time on something I don’t agree with but it turns out that no discussions will change the mind of the original contributors. They just strongly believe in their ideas. They will keep proposing the same idea over and over again (for years) till it gets published as an RFC..
> I don't understand why so many are opposed to publishing a document that merely describes how operators manage protocols in the absence of header encryption, and how header encryption interferes with those practices. That is, at least, in its original form, before this WG decided it needed to incorporate pro-encryption advocacy, greatly complicating the document and the resulting analysis.
> For the OG version, I ask myself the following questions:
> Does the document describe reality? Yes: it tells us what practices operators employ today.
> Is the document useful? Yes: see above, plus it makes clear that there will be an impact to operators and/or protocol users from this evolution.
> Does the document establish an IETF position on encryption? No. There are plenty of other published RFCs that embody the spirit "encrypt all the things". This document does not change that.
> Does the document make normative statements about future protocol development? No.
> On what basis would I therefore oppose publication?
> I may or may not have opinions about prioritization of user privacy over manageability, the tussle between manageability and deployability, and what alternatives are available to operators for managing protocols with encrypted headers. I would be happy to help express those in a follow-on document. But this document describing where those conflicts lie is a *prerequisite* to developing those alternatives. And frankly those opinions are irrelevant to the intended content of *this* document.
> Kyle
> _______________________________________________
> Int-area mailing list
> <>
> <>