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

Martin Duke <> Fri, 13 March 2020 17:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 949E53A0031 for <>; Fri, 13 Mar 2020 10:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 KnXtf0DSJWpV for <>; Fri, 13 Mar 2020 10:30:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7339C3A0028 for <>; Fri, 13 Mar 2020 10:30:35 -0700 (PDT)
Received: by with SMTP id 6so13133427wre.4 for <>; Fri, 13 Mar 2020 10:30:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yaQ1txxCs46AopM/cBfUyW3eUWh78mVMYqVc6tisLks=; b=iadMMOp8RlyiVBF8AgbcY8f/tqq67nY1wio9KT0JQynRpz4zJ9sLKPAMHYqfaGIdY2 g2j9LPby/E3up5iq7DcYhPYnfkOQhPvgP5qgP3yZG5KaVgwj1m+7ddNVzjAuU969Zs0H FU+JnJZdCtvwoZhG4uSKqxq/3DfIH/Fm8mJ95/FCwV6RR7u/qJkSMYzkNGIwlBIOAtw3 7T2JwKA7Of7e1zwIZHpX+gE4E+alARz2kP66qMXyQDtQf1acZuVChFvSNQIjpNgbQlDU zwRqKbf5m5+kY4ChmeAVGjBZH4l5a8B+plzDEewNTyZfsySS0GmZm7qt8jrhg9oFRNM+ BN0g==
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=yaQ1txxCs46AopM/cBfUyW3eUWh78mVMYqVc6tisLks=; b=PRLdlW4Q+Ph5v2298h4EWKApCS7KABNjn/e1Fz0L+tujSc696RTYmKJAqsEoK58Xvr iTaKOtxacc54pbsVczwgse4O6NycGrKBYQj42oiYJt9Gwa93BJbj2k9hbIiVHY789JDK knHKcm5zXNVV2RYVKEfDedbBC7g5metKn6tkJ+KYIV8yoAb/kAcVYmdLU7fIarvLxM2O k0jPrf0tNMuAn60FvrEM8+cJJ3I4c0F4Hf08mTkMzAcVg603PiJjg8UF27TdR2OjEult KekAqVgTF5qdTaVaIYJYJn2WA8PZT4DMSd+aTf4NNMvL2bdo7K0uhcbZeDWY+f6PazYt a1Mw==
X-Gm-Message-State: ANhLgQ1y8r4sNkea2K2zy6Hp02oBUim+cuDNo5pO2s0vkHZWlIStvDig 3eIgRSlKq8pLemWi4jCGXuF9OWlNvGQSMQB8vHo=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsOFR1trS2JR1k1dctA120YcNx5GOdmjMpvu4fO?= =?utf-8?q?3aL4JcufYd8sUGZfpEJ0rFYdVBQUZEjQ8UVQAmxL/mT3TkU=3D?=
X-Received: by 2002:a5d:4049:: with SMTP id w9mr16080798wrp.158.1584120633684; Fri, 13 Mar 2020 10:30:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Fri, 13 Mar 2020 10:30:22 -0700
Message-ID: <>
To: Eric Rescorla <>
Cc: David Schinazi <>, Gorry Fairhurst <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000a6f7dd05a0bfd3cf"
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 17:30:40 -0000

I have no idea, but the draft isn't meant to be a point solution to loss
bits. I suspect loss bits are not the last time someone will want to expose
more info.

On Fri, Mar 13, 2020 at 9:41 AM Eric Rescorla <> wrote:

> 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?
> -Ekr
>> 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.