Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 27 February 2020 19:17 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 3523A3A097C for <tsvwg@ietfa.amsl.com>; Thu, 27 Feb 2020 11:17:50 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 BzIqd4a0I8ld for <tsvwg@ietfa.amsl.com>; Thu, 27 Feb 2020 11:17:47 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id A1FC63A096E for <tsvwg@ietf.org>; Thu, 27 Feb 2020 11:17:47 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D4C511B001C0; Thu, 27 Feb 2020 19:17:43 +0000 (GMT)
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
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>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <1a3178e6-cca4-ac62-d21e-1ce1e00d9ba5@erg.abdn.ac.uk>
Date: Thu, 27 Feb 2020 19:17:43 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <CAPDSy+5e0HYhBJdQm-ZhBcqmqwKGkpaKU8t_9R2_P=nAOs9s2w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CA2A0902F7A41427985D8D12"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/tomUp4ldbx58NMkW392KUqECmbo>
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: Thu, 27 Feb 2020 19:17:50 -0000
We discussed the scope a lot at the start, and the advice I received was that this is not the document to tell people about what they have to do. I think the decisions about whether to encrypt all transport fields or some or none isn't something I saw huge consensus upon. I did see many strong arguments, but what I heard often depended on which working group was speaking and the background of people involved. Had I asked a different question, e.g. do you think Privacy is important I would have got a different answer (we do have a BCP that notes that). The AD advice I recall at the time we asked to work on this, correct me Spencer if I am wrong, was to not attempt a BCP until the WG could first publish an informational document. This is that document. The purpose then, as I see, is to examine where we have arrived. Had we had a document like this, other discussions such as how to manage QUIC, whether PLUS could be useful, etc could have been more informed and focussed. Gorry On 27/02/2020 18:39, 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 <gorry@erg.abdn.ac.uk > <mailto: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