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

Eric Rescorla <> Fri, 13 March 2020 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B5BA3A0EB7 for <>; Fri, 13 Mar 2020 09:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 m5UZc4j7OtzA for <>; Fri, 13 Mar 2020 09:41:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 492D93A0EB6 for <>; Fri, 13 Mar 2020 09:41:25 -0700 (PDT)
Received: by with SMTP id n13so6611410lfh.5 for <>; Fri, 13 Mar 2020 09:41:25 -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; bh=ejtNN75CMgWpWLA61vQS8h+ke29Y7fBX1Mg6edSSrxY=; b=ay2qxfhYeQLIQw+LtA7goMZXr6Wc3XuSX46xpcn5RMgf2A4g0qZlX9BHa0UEUzJtwS 208xPzw7iGizwq5GNLlB9fmTfUQVdENlxFbrdd37tprzIwKbn14+Xjl+jcwKRwP8d+DI enRZyEkOg35t/ddo6EA6gNn3HtXUA4uSIG1hk4XSW/vAcqxfXdkH+FIu4u27aWZHPPwD d7hZsyRHL7Mr8hpUruNbCDP1Pz1cqOb2hhabwj2WGIxitSkdXyC8sRpIqWtrwNrD3yIk TXpXc+HOe6eFP1H6AZPw6zeXOwJM/TKNcXSx3GGhE1NM5id3ItcchyE+NbWkDyzukxmX mh6A==
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=ejtNN75CMgWpWLA61vQS8h+ke29Y7fBX1Mg6edSSrxY=; b=SY4YrKYlKGxVqA9mZao+ZiaZzHzRoFvSShXnaQxA77SUz8aRcTHBuDwzBY1CKC3EQc 9aRqo0xZ8iK8vBPH4KWJ+zEsAval6vhPWfUhTZAEprQu9zzGQOQh9nFBWmLrVbDC1ZPM L7Il2m3IWtV5Via4BLbf8GLKreINmlVWKS8667G3CnMAFUDYACrZH/G2clhpzNPlPypw fiekkMNZ/qrptgkZXgoaoA4WMUq9jhsrgvoLQ2clH3p3Jo2/tM+TCAUpIIlBCwyIkoLZ y8QsmKv8rrebh9UaZRylA2r5hmBUKL8zpbneA1bOxlgHr75RJelfsjep9yBPfjP3S0Wn b8JQ==
X-Gm-Message-State: ANhLgQ2hVPj0SkiIRN67H5visylt7VqJVfg89y+rrauvoND5xPDJ6kPI j6HaSEZEgUMXC8kAj0iMKDZvPqqYWXpS4sgYCQTXcw==
X-Google-Smtp-Source: ADFU+vsuhnre5OceJJdaIHOdZ2FGSMn4aHhEuoRzj6uXHJUZFxl+sfPWDv2Aqgqc4F0RmIPdagc+8J9Lcjtso5Kkaew=
X-Received: by 2002:ac2:5396:: with SMTP id g22mr3867111lfh.161.1584117683434; Fri, 13 Mar 2020 09:41:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Fri, 13 Mar 2020 09:40:47 -0700
Message-ID: <>
To: Martin Duke <>
Cc: David Schinazi <>, Gorry Fairhurst <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000cdcb1f05a0bf23ac"
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: Fri, 13 Mar 2020 16:41:28 -0000

On Fri, Mar 13, 2020 at 9:36 AM Martin Duke <> wrote:

> (With all hats off)
> ekr,
> I don't think the encrypt-or-don't decision is as binary as you suggest.
> Today, QUIC implementers can decide whether or not they will implement the
> spin bit. As you well know, QUIC loss bits are potentially coming down the
> way and this draft, in some form, may inform that discussion.

Perhaps, but what fraction of the practices in this document would be
enabled by even the loss bits?


> I'll abstain from any position on the tone of the document until I have a
> chance to re-read it.
> Martin
> On Fri, Mar 13, 2020 at 9:21 AM Eric Rescorla <> wrote:
>> Document: draft-ietf-tsvwg-transport-encrypt-12.txt
>> I more or less concur with David's comments.
>> First, it's really not clear what purpose this document serves.  While
>> superficially an analysis of the impact of transport layer encryption
>> as a guide to designers, in the context of the design and deployment
>> of QUIC and SCTP/DTLS, both of which encrypt most or all of the
>> transport header, it's hard not to read this document as an implicit
>> critique of those decisions. It's not like there's some other big
>> transport protocol design effort going on in IETF that would be
>> informed by these considerations.
>> With that said, I don't think we should neutral on this topic: the
>> last two newish transport protocol stacks that the IETF has designed
>> (SCTP/DTLS and QUIC) both incorporate transport header encryption and
>> I haven't heard anyone propose that we design a new protocol without
>> that, so I think any document that we publish should state that this
>> is a good thing while also documenting the challenges it creates.
>> However, this document isn't really even neutral: it spends vastly
>> more time on the negative impacts to non-endpoint network actors than
>> it does on the benefits to the endpoints, and while it does
>> acknowledge those benefits, they are often framed in a sort of "people
>> say" framing, which isn't really applied to the practices which are
>> negatively impacted, which are largely taken at face value. Compare
>> the following passages:
>>    o  One motive to encrypt transport headers is in response to
>>       perceptions that the network has become ossified, since traffic
>>       inspecting middleboxes prevent new protocols and mechanisms from
>>       being deployed.  One benefit of encrypting transport headers is
>>       that it can help improve the pace of transport development by
>>       eliminating interference by deployed middleboxes.
>> and:
>>    In some cases, network-layer use of transport header information can
>>    be benign or advantageous to the protocol (e.g., recognising the
>>    start of a TCP connection, providing header compression for a Secure
>>    RTP flow, or explicitly using exposed protocol information to provide
>>    consistent decisions by on-path devices).  Header compression (e.g.,
>>    [RFC5795]) depends understanding of transport header and the way
>>    fields change packet-by-packet; as also do techniques to improve TCP
>>    performance by transparent modification of acknowledgement traffic
>>    [RFC3449].  Introducing a new transport protocol or changes to
>>    existing transport header information prevent these methods being
>>    used or require the network devices to be updated.
>> In the first passage, the use "in response to perceptions" creates
>> the impression that ossification is just some people's opinion,
>> whereas it seems to me that it is a commonly understood fact of
>> the network that has been an obstacle to deployment of everything
>> from DNSSEC to TLS 1.3. By contrast, the second passage implies
>> that tampering with acknowledgments is "benign or advantageous"
>> when there is actually quite a bit of debate about whether
>> this is a good idea (although I recognize that you are citing
>> a BCP which recommends it).
>> A second way in which this document is non-neutral is that it focuses
>> largely on network-side interventions which seem to be well-intended
>> (i.e., the operator is attempting to serve the users
>> interests). However, there are also a wide variety of interventions
>> which are adverse to the users interests (e.g.., RST spoofing, as is
>> done by the Great Firewall [0]). By focusing on the downsides of
>> encryption
>> while minimizing the harms that encryption is intended to prevent
>> this document again comes off as largely a critique of transport
>> layer encryption in general.
>> For these reasons, I don't think that this document should be published
>> without extensive revision.
>> -Ekr
>> [0]
>> On Thu, Feb 27, 2020 at 10:40 AM David Schinazi <>
>> wrote:
>>> Hi Gorry,
>>> Thanks for updating the document, and for slightly tweaking the
>>> tone to focus less strongly on the downsides of transport header
>>> encryption. It's much appreciated.
>>> However, I'm now pretty confused by the latest version (-12).
>>> Could you help me answer these two questions please:
>>> 1) Who is the target audience for this document?
>>> 2) What should that audience walk away with?
>>> I initially assumed that the answer to (1) was "designers
>>> of new transport protocols". But considering myself in that
>>> category, I don't know what I'm supposed to take away
>>> from the draft. I was expecting the answer to (2) to be
>>> "you SHOULD or SHOULD NOT encrypt transport protocol
>>> headers (pick one)" but that's not the case.
>>> Here are excerpts from the draft's Conclusion section:
>>>    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.
>>>    This document does not make recommendations about what
>>>    information ought to be exposed, to whom it ought to be observable,
>>>    or how this will be achieved.
>>>    An appropriate balance will emerge over time as real instances
>>>    of this tension are analysed [RFC7258].
>>> The messages I'm walking away with are:
>>> A) there is a tension between folks who want to encrypt and
>>>     folks who don't
>>> B) we don't have enough information, it's too early to tell what the
>>>     impact of transport header encryption really is
>>> As such, I'm now more confused than I was before reading the
>>> draft, as it doesn't help me answer the question of "when designing
>>> a new transport protocol, should I be encrypting my transport
>>> headers or not?".
>>> I personally oppose publication of the document as it stands,
>>> because I find it confusing and non-actionable. I would like to see
>>> this useful content in a BCP document once we have enough
>>> information to actually recommend something.
>>> Thanks,
>>> David
>>> On Thu, Feb 27, 2020 at 1:09 AM Gorry Fairhurst <>
>>> wrote:
>>>> The editors have just uploaded a new revision of
>>>> draft-ietf-tsvwg-transport-encrypt following review comments. We are
>>>> not
>>>> aware of further review comments and now think that this new version is
>>>> now ready to proceed.
>>>> Best wishes,
>>>> Gorry and Colin
>>>> ---
>>>> A new version of I-D, draft-ietf-tsvwg-transport-encrypt-12.txt
>>>> has been successfully submitted by Godred Fairhurst and posted to the
>>>> IETF repository.
>>>> Name: draft-ietf-tsvwg-transport-encrypt
>>>> Revision: 12
>>>> Title: Considerations around Transport Header Confidentiality, Network
>>>> Operations, and the Evolution of Internet Transport Protocols
>>>> Document date: 2020-02-26
>>>> Group: tsvwg
>>>> Pages: 48
>>>> URL:
>>>> Status:
>>>> <>
>>>> Htmlized:
>>>> Htmlized:
>>>> Diff:
>>>> Abstract:
>>>> To protect user data and privacy, Internet transport protocols have
>>>> supported payload encryption and authentication for some time. Such
>>>> encryption and authentication is now also starting to be applied to
>>>> the transport protocol headers. This helps avoid transport protocol
>>>> ossification by middleboxes, while also protecting metadata about the
>>>> communication. Current operational practice in some networks inspect
>>>> transport header information within the network, but this is no
>>>> longer possible when those transport headers are encrypted. This
>>>> document discusses the possible impact when network traffic uses a
>>>> protocol with an encrypted transport header. It suggests issues to
>>>> consider when designing new transport protocols, to account for
>>>> network operations, prevent network ossification, enable transport
>>>> evolution, and respect user privacy.