Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
Eric Rescorla <ekr@rtfm.com> Fri, 13 March 2020 16:20 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 6122D3A0DC0
for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 09:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3FTPIvs4Ac7i for <tsvwg@ietfa.amsl.com>;
Fri, 13 Mar 2020 09:20:52 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
[IPv6:2a00:1450:4864:20::230])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 0EBAD3A0D9B
for <tsvwg@ietf.org>; Fri, 13 Mar 2020 09:20:51 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id a10so11142392ljp.11
for <tsvwg@ietf.org>; Fri, 13 Mar 2020 09:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=rtfm-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=UmLNuPJ4k+OnKyLaaWvSVrTBqQlQfwv39gyOwPGKhqI=;
b=npxhImzoWiAH/mh48ataUMgBDaBBxNm78smLZleT9FagyAE3ntesqZQFKCx8n7opsY
BkD1NILReGGUlf+bRY8z2Q8FHRNhnpZ4q0GUGjPCcg4E66gJt8+WyJGIvMbyNZ8lFS1M
Q8rt3aVHo4DDGLmf6bm6q+T8ajUwm3wC4iaYylS8qp1yjcGGrMWUtEXPdhFrgIw5R7bw
QFT6gSICGXyMtcDaLfE1ioQhJzTlgB5PAr8p3XmoBMkoL/MjubbBoOoKbmN+FKeCQeNL
rWxiWloRLeV8LWyVVpvOMN3lh2JPXov9vcNAiipYwvT3DzJosjB3fTdn5BMpgsxsRlxv
9aiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=UmLNuPJ4k+OnKyLaaWvSVrTBqQlQfwv39gyOwPGKhqI=;
b=BPrThpXlcA6pZmktyvzui9b+c9Authxn2QwoS4cm+1fJHOa7HlLHLcPfWc8sVj2YQD
EV801kqzllOcDSxgMOSc2vKLOz7TDVRwplhZXA+WEg95ZWaJUvXV1zrirJvFjE1MGePZ
gUDF3Lep9qDdYhQIbR+WlFJOD91Pq4nayAmLW0DdaU3iO2kQ2C3RWWTglHATF4zuYZXZ
ZZb64kdJpGBIwqg0JCJAb2cu/xuRuUwY6X0Bc4QfhimbYvUkcmDiK6UCLIEgjEz7spZi
o4rYHOMpUY49EVQSG6rO8bQ4PWV2nsr9jyQF74e7UORSsJqP8bJZdK8+H8YBDtckkQFm
EGuQ==
X-Gm-Message-State: ANhLgQ1bpXNwkDfdVr1fhM40WWst07D+x2Ps1/+vgdzIQohw47D1ZDgG
BigKLXIGc8CsVvUVA+jPkglWwI4imKTqVKb2iIq8RA==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsDdpieEmbU9HeOiZYA+AVHVeeVZazevspm7Q9M?=
=?utf-8?q?69xHfF/uyhmuGiQSqotkrZ0K2jVF4ujc3oQ1gq/ubX/spD8=3D?=
X-Received: by 2002:a2e:b0c9:: with SMTP id g9mr8354826ljl.120.1584116449126;
Fri, 13 Mar 2020 09:20:49 -0700 (PDT)
MIME-Version: 1.0
References: <158279435525.6196.11790581771168846041.idtracker@ietfa.amsl.com>
<3c7f9e3c-d4f6-b002-5e16-6611d654c8eb@erg.abdn.ac.uk>
<CAPDSy+5e0HYhBJdQm-ZhBcqmqwKGkpaKU8t_9R2_P=nAOs9s2w@mail.gmail.com>
In-Reply-To:
<CAPDSy+5e0HYhBJdQm-ZhBcqmqwKGkpaKU8t_9R2_P=nAOs9s2w@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 13 Mar 2020 09:20:12 -0700
Message-ID:
<CABcZeBOdDU0zQ+ZNQqu1vDWxQuLUzGqi9MMXPDUs-izZEgVQsg@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003be5dc05a0beda5b"
Archived-At:
<https://mailarchive.ietf.org/arch/msg/tsvwg/PFOEyX87p6ebXWZY_LDKuPyl3fY>
Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>,
<mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>,
<mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 16:20:56 -0000
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] https://www.cl.cam.ac.uk/~rnc1/ignoring.pdf On Thu, Feb 27, 2020 at 10:40 AM David Schinazi <dschinazi.ietf@gmail.com> 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 <gorry@erg.abdn.ac.uk> > 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: >> >> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-transport-encrypt-12.txt >> Status: >> https://datatracker.ietf..org/doc/draft-ietf-tsvwg-transport-encrypt/ >> <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/> >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-12 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-12 >> >> 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. >> >>
- [tsvwg] New Version of draft-ietf-tsvwg-transport… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… David Schinazi
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Spencer Dawkins at IETF
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Martin Duke
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Spencer Dawkins at IETF
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Joe Touch
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Colin Perkins
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Martin Duke
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Martin Duke
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Black, David
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Black, David