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

Joe Touch <> Thu, 27 February 2020 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D7263A07C6 for <>; Thu, 27 Feb 2020 15:02:58 -0800 (PST)
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 aEroBBPt5bPx for <>; Thu, 27 Feb 2020 15:02:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 600233A07B0 for <>; Thu, 27 Feb 2020 15:02:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=d8A7VsDKXAjvgfazJY3ouEh1F254msdv/DvZhuOCd3M=; b=tsQowc2kijyeBzoMdr1leOJHW MfJgrAvcUkJSHHiYPHalA2ZV5FN9/stgpUh/BdRz4p3SXJRD6Od5aCpb0dxF/6j2FNLQcpLRutVbZ 0Jz//CkRMhwCfq3+lKCoAlsi9dtnECjaJAknvZMaXuglQMwLO0hBfNfSR1mbqowtClC3CuBNybmUy pfj4oy4f1KwMeCmyCEVPaqVClSOWqdOf/lsQwMnpBSLSdMBldyjJzctgAxChuKtMyQCOv5I0ir0p6 yezXitq7G5swrEPA0i6T5upadQ8egKoa7mU9EntuZwA0XWTPU0ZxZ3vAnLIGEGo7K+Dfu3ri3jYic gD5L9ZJBA==;
Received: from [::1] (port=34500 by with esmtpa (Exim 4.92) (envelope-from <>) id 1j7SBA-001Pmj-EG; Thu, 27 Feb 2020 18:02:56 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_3f9ce2fbbd739acbcbdc1c9277e43e41"
Date: Thu, 27 Feb 2020 15:02:52 -0800
From: Joe Touch <>
To: Martin Duke <>
Cc: Spencer Dawkins at IETF <>, Gorry Fairhurst <>,
In-Reply-To: <>
References: <> <> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.3.7
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] 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 23:03:05 -0000

On 2020-02-27 13:26, Martin Duke wrote:

> One thing that came out of the spin bit discussion is that some transport protocol experts honestly do not understand how this information is used constructively in the network.

replace "how this info is used" with "why this info needs to be used",
and yeah - I'll claim to be one of them (if you can call me an expert). 

My concerns with the initial doc was that it was skewed towards "get out
of the way of network admins who need to snoop into your private
business to 'help them help you'". I think the current design is a much
better balance and reasonable as a way forward.  In particular, it seems
to say more "if you want that help, then be careful to make the needed
information available at some protocol layer", rather than "leave your
doors unlocked, because we really want to help you and that's the only
way we can".