Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Tom Herbert <> Sat, 12 October 2019 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FEA412085F for <>; Sat, 12 Oct 2019 09:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 ByPU890mAXLN for <>; Sat, 12 Oct 2019 09:01:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 001A512085A for <>; Sat, 12 Oct 2019 09:01:57 -0700 (PDT)
Received: by with SMTP id t3so11197117edw.13 for <>; Sat, 12 Oct 2019 09:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Z3x5o7yD5aMKJJ05GmaR0MgoZPKTCbzAWzCfCkd17ak=; b=g86ottmTZc7ctUkf/J5VxTlta1K81G5qLafUUpl8xiKtbif21f3kBJ7srqLm2BZYjx 1wW1vvlZ2erEyXHRkcW0IeviQQiNIMJRiPd1js3EsqDwHYMPBvglvV2wB9jWr0udnayR pLXiJEtqEUFQpGcisDuxZ1gEbFqQ8S+oMZnToXqCySQj2tR7o90oyYTzhkj3qpFp0CKD Pk5eDEHmS4x3xzNfGZXdz3nt6lBFsrIkLMIrUjmUWcpt5Ou0W+hCFVIOUcbMuhXO3Tg+ 9jsnhz8N9B3+aN3jtxqx6pV/473fbRyoiRcH5DOu1qiDKdB60aJfEgNWmJDHAl/lZ/9O +Mvw==
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:content-transfer-encoding; bh=Z3x5o7yD5aMKJJ05GmaR0MgoZPKTCbzAWzCfCkd17ak=; b=LEquZpzso5hdkg+ZyAm+gnfp4w4oQJmU3ewuzIAAvQaZEsVr5hffR6bWpbBg42CJo9 tO4yqVl4CJjyaQYrUiR29pPdqSu/OBGZVcTujKwdEmEveUWY8m8hfGn4oFPxzsfnURyN JgCvU1Qn4nRkyKwLeV+MvU5jDXtBUxYflmoMYTQ+ibO1pW/Tvtv8DynQoZIuAoOPKYih iprt/9OceDesCtDTetonMNUWA3BwRtOrEmP50qadSGT0B3ySF0G2wa2HNaw1NFKo2PTM lhUc7m7qTzwlxOSwxqN+VuisLVRYcwq/t/+dumXad1MguS/q4YPVv3gVJGdf9Gmckq9N QfcQ==
X-Gm-Message-State: APjAAAX5ciBXSmcg/VvwGbrXOFQttLcR+Qf3jSHguQA68CZVrT+e3jyX 7dj7DvvFD55sX1mPRYCZ5ci16u2P38BvWTgoLo9p8A==
X-Google-Smtp-Source: APXvYqxhg4pWrV1TFNj4mLtujWhLsvDQO9GU1OcXYM/ODdACH0nUpq9yZo6ynjyXYtizdEImkRQA3GNQwokekAk096o=
X-Received: by 2002:a05:6402:6c6:: with SMTP id n6mr19636466edy.292.1570896116264; Sat, 12 Oct 2019 09:01:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Sat, 12 Oct 2019 09:01:44 -0700
Message-ID: <>
To: Joe Touch <>
Cc: Christian Huitema <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
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: Sat, 12 Oct 2019 16:02:00 -0000

On Wed, Oct 9, 2019 at 7:39 AM Joe Touch <> wrote:
> +1
> IMO, this isn’t a “tussle” so much as “I really want to do something I know I shouldn’t be doing”.

I don't see a tussle here. Transport headers are E2E protocols and
were never designed to be consumed by intermediate nodes. Any use case
of intermediate nodes consuming information in the transport layer
header, with the possible exception of NAT, is ad hoc and
non-conformant with the standard. Per the Internet architecture
exposure of this information is not required for routing packets
through intermediate devices, encrypting transport headers is
consistent with the architecture and closes a security hole. As a
transport protocol developer, the _only_ reason I wouldn't encrypt the
transport header is if that is the only way to get packets to a
destination; the possibility there _might_ be some benevolent node in
the network providing some ad hoc benefit users is not enough
justification for sending transport headers in plain text.

I do believe that there will be valid use cases for hosts to signal
the network for services. There is a least one robust, explicit, and
transport agnostic method to allow hosts to signal the network with
transport related information and even application layer information--
that's Hop-by-Hop Options extension header. A critical difference with
parsing transport layers, is that the end host is in control of what
information is exposed in HBH options. As I've said several times, I
believe this draft is missing on the opportunity to propose this as
the "solution" to middleboxes losing visibility because of encryption.
Also, I think the encryption and the perceived loss of visibility is
inevitable anyway so we do need a real solution. (this story is eerily
and the arguments from middlebox view is eerily similar to when TLS
was turned up in the Internet).


> A lot of what transport security prevents is - from the middlebox view - a problem.
> For many of us users, preventing middleboxes from doing things like hijacking web, email, and DNS is *exactly* the protection we were seeking.
> Joe
> On Oct 9, 2019, at 7:32 AM, Christian Huitema <> wrote:
> As the draft mentions:
>    The use of transport layer authentication and encryption exposes a
>    tussle between middlebox vendors, operators, applications developers
>    and users
> Much of the draft reads like a lamentation of the horrible consequences of encrypting transport headers, which looks very much like embracing the point of view of the middlebox vendors. Expressing that point of view is of course fine, and it might be enough to change the title, abstract and introduction to reflect that this is an opinion piece. But as a transport working group document I would like something a bit more balanced. It should spend more time acknowledging the ossification and privacy issues. It should ideally lay the ground work for alternative management solutions, such as controlled exposure like the spin bit in QUIC, IP header information, or standardized logs like the QLOG effort.
> -- Christian Huitema
> On 10/8/2019 2:08 PM, Black, David wrote:
> FYI – some OPS area and SEC area eyes on this TSVWG draft now (during WGLC) would be a good thing ;-).
> Thanks, --David (TSVWG co-chair)
> From: Black, David <>
> Sent: Tuesday, October 8, 2019 5:06 PM
> To:
> Cc: Black, David
> Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
> This email announces a TSVWG Working Group Last Call (WGLC) on:
> The Impact of Transport Header Confidentiality on Network Operation and
>                        Evolution of the Internet
>                  draft-ietf-tsvwg-transport-encrypt-08
> This draft is intended to become an Informational RFC.
> This WGLC will run through the end of the day on Wednesday, October 23.
> That should allow time before the Singapore draft submission cutoff for
> the authors to revise the draft with any changes that result from WGLC.
> Comments should be sent to the list, although purely
> editorial comments may be sent directly to the authors. Please cc: the
> WG chairs at  if you would like the chairs to
> track such editorial comments as part of the WGLC process.
> No IPR disclosures have been submitted directly on this draft.
> Thanks,
> David, Gorry and Wes
> (TSVWG Co-Chairs)
> _______________________________________________
> saag mailing list