Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
Eric Rescorla <ekr@rtfm.com> Fri, 13 March 2020 16:41 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 4B5BA3A0EB7 for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 09:41:28 -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 m5UZc4j7OtzA for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 09:41:25 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 492D93A0EB6 for <tsvwg@ietf.org>; Fri, 13 Mar 2020 09:41:25 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id n13so6611410lfh.5 for <tsvwg@ietf.org>; Fri, 13 Mar 2020 09:41:25 -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=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; d=1e100.net; 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: <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> <CABcZeBOdDU0zQ+ZNQqu1vDWxQuLUzGqi9MMXPDUs-izZEgVQsg@mail.gmail.com> <CAM4esxTA9mheGALtp4zKKYVV7wNUfhp-0pdt3C62G=tkTQhaDQ@mail.gmail.com>
In-Reply-To: <CAM4esxTA9mheGALtp4zKKYVV7wNUfhp-0pdt3C62G=tkTQhaDQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 13 Mar 2020 09:40:47 -0700
Message-ID: <CABcZeBOPxLWfT3Un=+_DQoaP5Zf0_COJ=cBLsVwMZHGgu5BOHw@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cdcb1f05a0bf23ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Kw3cNOCIBNMh_TJRzgeyMgZpnhU>
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:41:28 -0000
On Fri, Mar 13, 2020 at 9:36 AM Martin Duke <martin.h.duke@gmail.com> 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 <ekr@rtfm.com> 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] 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