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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 21 November 2019 03:10 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 0C8D7120926; Wed, 20 Nov 2019 19:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 O0vlmTpCeH65; Wed, 20 Nov 2019 19:10:45 -0800 (PST)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7D71207FF; Wed, 20 Nov 2019 19:10:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1574305846; x=1605841846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XzCXBHi3aSkoJfU+gpREN6dMC56Gm668jZKSffNhPtc=; b=jjGbooZFOHqV9oPeVL/ohHDsIHmp9wdKztX+pGNVDOVRzdLBRo44Oko8 45ABnRfjMfkQ97k2auB7ELqbwYb9ePLCZQh5AurV6E8o66SV09I6izMcy Ly8duZ6RU8DTuBWRmweIkr7DWxt81/Iry/cbjNe1W/6jr2mD3+jOMVpVo TL71HldEuF+tb8qB6TqaYGG0zvICvN3wfzvakuUh51RbhD4xFBwyXd2In wdzZ5aDyPAWbu/G61Ae6DCHluL1+fuvhQWpBlALR1b7DALkOlizly6WUz o6rs7FlSOoCHq4TTtqGg9zN9GBnirtuOJg9CXD8xLavhq18gXbeJeg9/j w==;
X-IronPort-AV: E=Sophos;i="5.69,224,1571655600"; d="scan'208";a="100921991"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Nov 2019 16:10:43 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Nov 2019 16:10:42 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 21 Nov 2019 16:10:42 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Tom Herbert <tom@herbertland.com>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, David Schinazi <dschinazi.ietf@gmail.com>, Joe Touch <touch@strayalpha.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVlYavl0m+OZkGmkq1dk9tU/YKeqeHJEC3///AeQCADiJ0+g==
Date: Thu, 21 Nov 2019 03:10:41 +0000
Message-ID: <1574305843485.83458@cs.auckland.ac.nz>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com> <CAPDSy+5rvaXgEGZ7_V4pRdmBss7Hf1XmaGbiXGZceQu9hjjRTQ@mail.gmail.com> <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz> <CALx6S36-44Ya9eMEjzCHA=Le5dTBd+ENuY3GQd5Jv691LUQDAQ@mail.gmail.com> <1573542420083.60501@cs.auckland.ac.nz>, <CALx6S35bi7cwJFKk2m3dh7GEBGuj3eBXi87X9QjDdJ=YkJtYyw@mail.gmail.com>
In-Reply-To: <CALx6S35bi7cwJFKk2m3dh7GEBGuj3eBXi87X9QjDdJ=YkJtYyw@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/7-d5PK8TXKfQSeHqvcUvwzxCMsk>
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: Thu, 21 Nov 2019 03:10:48 -0000

Tom Herbert <tom@herbertland.com> writes:

>https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_huitema.pdf
>describes with some detail how encryption of the transport layer is
>beneficial to resolve the tussel that results in protocol ossification.

I'd always assumed the push for header encryption was due to some vague
handwaving about privacy or something else that's never really been made
clear, but from the above document it looks like the motivation is purely
ideological ("If we want to break that ossification, we have to do something
drastic", "we can score at least a partial win for end-to-end connectivity",
"application developers win a similar tussle", "reverses the balance of power
between end-to-end and middle-boxes"), which indicates that it'll end up as a
repeat of the IPsec debacle ("Let's make sure IPsec breaks NAT, because IPsec
will be bigger than NAT and so NAT will have to go away").

Someone really needs to do a proper design document and threat model for this
if it's that unclear what the goals of header protection are - is it for some
sort of privacy thing, an ideological move because people don't like
middleboxes, something to thwart the lizard people, to impress Jodie Foster,
or what?

Might I suggest that the IETF suspend any further push towards header
encryption until someone can figure out:

a. Why we're doing this.

b. What its intended goals and effects are.

c. Whether those goals will be met in practice.

d. Whether it will work when deployed in the real world.

At the moment it looks like (a) is at best very unclear and (b), (c), and (d)
are pretty much nonexistent.

Peter.