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

Tom Herbert <> Mon, 16 March 2020 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 669F63A0A1B for <>; Mon, 16 Mar 2020 08:21:54 -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, 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 dqy2Nar4EC0h for <>; Mon, 16 Mar 2020 08:21:53 -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 E28303A0A18 for <>; Mon, 16 Mar 2020 08:21:42 -0700 (PDT)
Received: by with SMTP id a43so654520edf.6 for <>; Mon, 16 Mar 2020 08:21:42 -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=JY6PB/0z4aC3upwSHgK2eTvDDCsCacK6H4qY1An0LYw=; b=rde+F2D4WYqB2OIGUwA4dUuDlTYM0U1t4FmcxKQJA/KWnGGeuqrycafDVRozf81pW/ +MAlmsbTiipZG56iU0dzdV3oTTEsaMS2Gmb7ysbYxx8peKHzMAyxagBH6F9XJPJSnyNi pTQZU0qykQfcH4Xu71hKazFbH0u8OWDaW1ecUCvGtPs5Nw0QZFD5/ho3zMuNpRGwz/hL lbsIdwrZEEFn75yRtWFSohzM/8svy8TQnNZJkj0j0BkrlqTLscRe9Qgf1FCwnCiPREJu 8Qs03CHrENM6c9dk+i1ah2RfLU3u3DHPnQtY7BDksVb40HhXyN0FtwmA3e3/mJK3gQDA xEZw==
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=JY6PB/0z4aC3upwSHgK2eTvDDCsCacK6H4qY1An0LYw=; b=ktVoh711xoMoYhs5xik3YNTwV9TPscLQjYHa9k1QXhVce9DC0inQsmkimazlGMzD3u gEAOw4x1UbBYkqQ2gh31OkrZD0XWOuGZxERI5wAdC4ZeVfJp6oII4BZGAEKB5VEsNCAZ 5I7zKc+MKd6m29r5fr0Wp6h4+6nWRPPDAStGcXIDPiPeEMXd5rqM+FhEkQ9jnYb6hHFz 8agXcym1taleIp8V68lgMtqvtHhx9738H50WFg9kKJFndvu4+mZxzCsmTd7Afmz1uo/5 egyWRHMfWo+OSx0tBHDn1fju0B9fQnrX6vgrBAcqd4vtr94lRf8+Kcp23qh2RWLlJ9PU 0xNQ==
X-Gm-Message-State: ANhLgQ2y7LJnhlaAOw8u175HVnBQv+B4ohJ0ggk17mqbKB5dr3TwHEvJ bBEzGOznrRYbKbFbMRIROQ2xgRtGXdqFA3mhCspg2wgpouo=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuzUYp9YA8CGiTG3CKFAujU0erz1w5iyh0b+B4k?= =?utf-8?q?2w7YI1w01dix4LQ3nVySPaqWJPpyIq9Jlmc+oDq1N5zChHo=3D?=
X-Received: by 2002:aa7:d381:: with SMTP id x1mr458387edq.212.1584372101021; Mon, 16 Mar 2020 08:21:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Mon, 16 Mar 2020 08:21:29 -0700
Message-ID: <>
To: Gorry Fairhurst <>
Cc: Eric Rescorla <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Mon, 16 Mar 2020 15:21:55 -0000

On Mon, Mar 16, 2020 at 7:52 AM Gorry Fairhurst <> wrote:
> On 16/03/2020 13:06, Eric Rescorla wrote:
> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst <> wrote:
>> Ekr,
>> On 15/03/2020 13:19, Eric Rescorla wrote:
>> Let me try to expand my point a bit.
>> Longstanding practice is for entities in the middle of the network to
>> use signals that were intended for the endpoint for their own
>> purposes.  With QUIC (and a lesser extent SCTP/DTLS), those signals
>> are being encrypted and thus unavailable to those non-endpoint
>> entities; this draft is mostly devoted to documenting the negative
>> impact of that change on the operations of those entities.
>> I disagree that this is "documenting the negative impact of that change".
>> The draft is about how this protocol information has and is being used. As long as I can remember, there has been devices that utilise some of this information, at the edge of an enterprise there is often at least one device with this role; within a managed network there are devices; etc. If the trend to use encrypted methods continues, some of these practices need to be re-assessed, and the functions more widely understood than in an era when nearly everything was thought to be TCP or "multimedia".
> I'm not sure what you're arguing here. What I said above is that
> this draft was "mostly devoted to documenting the negative
> impact of that change on the operations of those entities."
> In other words, it lists a bunch of things that people do now
> that will stop working. Do you not think that much of the
> material in this draft is of that form?
> -Ekr
> So the conclusion, para 2 states:
> "   This document has described some current practises, and the
>    implications for some stakeholders, when transport layer header
>    encryption is used.  It does not judge whether these practises are
>    necessary, or endorse the use of any specific practise.

Section 5.2 states:

"Current measurement results suggest that it could currently be
undesirable to rely on methods requiring end-to-end support of network
options or extension headers across the Internet."

That _is_ a subjective judgment about a technique that is not
currently used with little discussion on why they're undesirable or
what needs to be done to make them desirable. As I've said before, I
think the document is too easily dismisses this alternative. If the
point of this document is to describe the implications of transport
header encryption without any diligent consideration of alternatives
to expose the necessary transport information to the network, then I
suggest that the discussion of extension headers and other
alternatives should be removed and deferred to other documents.


> I agree many existing tools would stop working if IPsec formed the majority of traffic, same for QUIC. I think when considering what to do next, it can be useful to work from the current position and understand the implications of changes that are being proposed/used/whatever.
> At least from my personal position, this document was providing some input to that thinking. So, I do not understand your issue.
> Gorry