Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

"Martin Thomson" <mt@lowentropy.net> Wed, 06 November 2019 04:10 UTC

Return-Path: <mt@lowentropy.net>
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 68C4312004D; Tue, 5 Nov 2019 20:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ITb3JIF4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MxQFyLCx
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 VBDnCFYWL3yL; Tue, 5 Nov 2019 20:10:21 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CCD12002E; Tue, 5 Nov 2019 20:10:21 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B9F7D21A92; Tue, 5 Nov 2019 23:10:19 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 05 Nov 2019 23:10:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=ST z3GdKSIj/u5/+p4J10CA0Bswh0HWRR8oAKYUkK+CU=; b=ITb3JIF4fEbW1KT2rX bLviQ6BZHHkYk8xYowtCbFQc+Jv5TQqnS0kOUEquP9Jfj5x4dmvoap/u2ELZ3Hay WECC0BLTejaVIEQw9z3mIXJ+oH6/6G/redtWej2jkLAe27UGFffTWcOH8mH8bQQT MJZtK5rW+j79uvsZHsAhvj6kpCNSuVow8SmLtHP0PRb+tM0qPnaEtGi2O2heiwtq DMfEtVXvyA0cea7QHSzjAs1ahG+1QiGCnSQ+s6EkOB+PozbRJppnjA0oM/6Al4a3 9HRMSwLnFYlxil+dzXOfCUR4U4wqjcaU/VPEFIUPheYlUcLRB6a5zP5JPtBRIb1G /8oQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=STz3GdKSIj/u5/+p4J10CA0Bswh0HWRR8oAKYUkK+ CU=; b=MxQFyLCxPfgafFvvdzPLEWzWYto4O4zwrIleELafSgnRwgdNb/ydGL3eV odGtb/nyjs++C7rG+aw8YdPTwtyZRP4RMtwcCusBfo5DtVDmDRHt8KCY403pgV1U emND/2Gb5bIDWjv6CmDBpoEmdcqqe0xnHz0xVeRrrhzmby4zoNFOsQsYb7n64ji+ IQw0n6yzwDFUIC7G717WfvvfYzLOAyp+0qeheUYM0nWOTSEQ2XxEjbgjEpDSauCk 7Q2k87eG4FALxSnBiFFfccFcpaH3iPuZeymoWh0fnRxY2wxeFIH5JRT2j+aPqCDH H/nSqXFrPwCzMwmt2s84Hx6yX1nKA==
X-ME-Sender: <xms:q0fCXRMxPztSUfD0RxuZiFSPpBa9otmtMKWCvRolAedn69vT46yfYQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduiedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmthes lhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:q0fCXQwHMRoUgq4qdzv-8jRx1rJYrWCzl0Y_Agf7qaDHp297DHKrnw> <xmx:q0fCXUdN7uKBrl88SFtzPj5u7O03EEtek4P_2gdUsO_E3hKZ-QnbXQ> <xmx:q0fCXb0a-LTjKUTRnoh95UJF7VcgyVlIEFBeLoQtJvH5wg_A0l-yQw> <xmx:q0fCXQs5WIGGjjxZzeh33DHVvp8e-qI4t_OfjHbIaE2SbB2nwckmgQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3B086E00A3; Tue, 5 Nov 2019 23:10:19 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com>
In-Reply-To: <CAPDSy+5rvaXgEGZ7_V4pRdmBss7Hf1XmaGbiXGZceQu9hjjRTQ@mail.gmail.com>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com> <CAPDSy+5rvaXgEGZ7_V4pRdmBss7Hf1XmaGbiXGZceQu9hjjRTQ@mail.gmail.com>
Date: Wed, 06 Nov 2019 15:09:59 +1100
From: Martin Thomson <mt@lowentropy.net>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/9X_vzpGISO7LdG1NTnJRdb7wtIw>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
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: Wed, 06 Nov 2019 04:10:23 -0000

I just read this document.  tl;dr, I agree with David, but I'd like to provide rationale in long-form.


The introductory material is largely quite good.  Though I found it to be a little long-winded and a bit repetitious, the thesis it sets up is an oft-repeated theme of recent discussion: encryption has these benefits, but increased deployment of encryption affects certain existing practices.  Add text on ossification.  In the abstract, that's all non-controversial.  The risk that this is a repetition of RFC8404 is tempered by the prospect that this document might include a more detailed analysis of transport-level mechanisms.

However, the remainder of the document says something different.  In reading Ekr's review here, I thought that might be through implication, but I found that it was far more direct.  There is an assumption throughout that the listed practices are privileged and therefore deserving of protection.  No attempt is made to acknowledge that some of these practices are can be harmful in various ways.  No recognition is given to the possibility that involving endpoints might offer alternative methods toward the same ends.  This is perhaps exemplified in the conclusion, which states:

> An increased pace of evolution therefore needs to be accompanied by methods that can be successfully deployed and used across operational networks.

And:

> Protocols that change their transport header format (wire image) or their behaviour (e.g., algorithms that are needed to classify and characterise the protocol), will require new network tooling to be developed to catch-up with each change.  

The use of "needs" and "will" in these statements is emblematic of the theme that carries throughout this conclusion and - to a lesser extent - the preceding sections: the document clearly states that these goals are important and stresses the importance of finding replacements.  For instance, I don't think it is appropriate for an on-path box to reset a flow that doesn't conform to some ideal (S3.2.4).  If I were to state the requirement for a network operator it would be that it be possible to identify and isolate sources of traffic that are consuming disproportionate amounts of resources.  That might avoid any implication that the network operator be able to measure goodput (S3.1.2), for instance.

End-to-middle and middle-to-end signaling is something this organization has repeatedly attempted to tackle.  It's a hard problem.  Success has been patchy.  Though we might debate relative success, successful signals are few in number.  This document contains a direct and specific plea.

It is possible that this problem could be addressed by adding water until this skew is sufficiently diluted.  Sadly, the homeopathic approach we took with RFC 8404 failed.  The IETF ended up publishing an RFC in the absence of consensus.  I don't see that tactic being any more effective in this case.  The catalogue of techniques here is somewhat interesting, even if it is now outdated as Bernard suggests.  A document with the right framing might work, but that would omit any conclusion other than the one that says that these techniques are approaching extinction.  Though that might be a shame in some ways - the loss of the ability to conduct research in some ways is a loss - those are the facts on the ground.

As this is a document that intends to represent consensus, I have to oppose publication on the grounds that it includes an ask I disagree with.  I assert that it would be better to concentrate on building those signals, even if it is one hard-earned bit at a time.  For instance, let's see how ECN and spin work out in QUIC.


On Wed, Nov 6, 2019, at 09:10, David Schinazi wrote:
> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This 
> document discourages transport header encryption and publishing it 
> could harm future protocol development.
> 
> David
> 
> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch <touch@strayalpha.com> wrote:
> > 
> > 
> >  > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org> wrote:
> >  > 
> >  > What I’m hearing is that 2-3 people think this is not aligned but don’t actually say why exactly they think that
> > 
> >  That’s not what we’re saying. We gave reasons. 
> > 
> >  Joe 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>