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

Kyle Rose <> Wed, 17 June 2020 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9F7B3A0855 for <>; Wed, 17 Jun 2020 08:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VUX_mbab5M2Q for <>; Wed, 17 Jun 2020 08:21:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B26053A0889 for <>; Wed, 17 Jun 2020 08:21:45 -0700 (PDT)
Received: by with SMTP id g44so880082uae.12 for <>; Wed, 17 Jun 2020 08:21:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YyMqZV4pNuYG9831TurjjwQSwvpR2t5loRgP28juT48=; b=m7JP+qfINPYjxY10HE+lUtEIDZEzrPyelEXFmTz4GQpwYq+SLvsn/oNtgZW99onrmM 6AUHHpH38eSEkEDrqWcHUQG+6w/3xQHfMtL7jnRyJOd03BygbCz6HlZhn7aADtPw7pqs NCkgqipVZMuvuCQYF1s3TMbFBAFduYU2hm33g=
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=YyMqZV4pNuYG9831TurjjwQSwvpR2t5loRgP28juT48=; b=S3XB8UJmfzVhustvfpxx/SpNZgHt7YZ0qMGV1C9MFA6/Sh2Gx8jLe4m0k8gT3lQBkr RyUJTyfbFLq546bxbLoQeUjbVme8zqbEnwrMNoZ0FSuE0ZZ2W9imTNlKv0PnaYRkuf+8 Rou0n7dbVbtnkhJTRroUR+2whwbE6KI5mMSqcQidJQxDkKVmzeY3KBZf11dnYrLnSHSJ WDy/UD+2VR8lyd1tXi1gvChTOrjYFiSFSxARsCbUvcWeupJjTbbkc0u7UYhE+sgGXu/x iRwvkJ8gz0eDILG6B7HlV0FhzO6wah4UxEvLcJ5w1/fn4SBWvaabtTiTR0WcLeiu7xxI VZbw==
X-Gm-Message-State: AOAM531YYnpRQTlgv6OZJeT+Shd4SPnIcxw3mDIUFgEavuN/gVvzS+4N rFiJBqcxFtBOZAtuND54sVjmZ9tfUK/KutrkB+Spjw==
X-Google-Smtp-Source: ABdhPJwUWlyypI1F6lYUlNFypwEhq/IrvWkWM+tQYxpV4NIXBN75pPlSV2wQKkiqDUl/zoZToSjN4oZA2takr+w28e8=
X-Received: by 2002:ab0:6445:: with SMTP id j5mr6258721uap.26.1592407304315; Wed, 17 Jun 2020 08:21:44 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Wed, 17 Jun 2020 11:21:32 -0400
Message-ID: <>
To: "Black, David" <>
Cc: "" <>, int-area <>, IETF SAAG <>
Content-Type: multipart/alternative; boundary="000000000000b6c76b05a849372b"
Archived-At: <>
Subject: Re: [tsvwg] [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, 17 Jun 2020 15:21:49 -0000

On Mon, Jun 8, 2020 at 9:41 PM Black, David <> wrote:

> This email announces a limited-scope 3rd TSVWG Working Group Last Call
> (WGLC) on:
>     Considerations around Transport Header Confidentiality, Network
>      Operations, and the Evolution of Internet Transport Protocols
>                  draft-ietf-tsvwg-transport-encrypt-15
> we have machines near IAD
> that Asgard can use vwg-transport-encrypt/
> <>
I support requesting publication of this draft as an informational RFC.

There's no reason a draft aimed exclusively at identifying,
contextualizing, and offering high-level mitigations for a set of related
technical problems (in this case, the operational problems exacerbated by
transport header encryption) needs to incorporate advocacy of any kind. It
is very clear from other publications and from on-going work that the
consensus of the IETF is in favor of measures to combat pervasive
surveillance and to limit protocol ossification. The purpose of *this*
document seems to be to end the pretense that there is no resulting
tradeoff or that by ignoring operational issues related to transport header
encryption they'll go away on their own. That said, even then it does not
in any way advocate against transport encryption, and is circumspect in its
proposals for measures to improve diagnostic visibility.