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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 07 November 2019 06:51 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 730D8120074; Wed, 6 Nov 2019 22:51:08 -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=ham 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 DphaOsJbbgD3; Wed, 6 Nov 2019 22:51:06 -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 6069212002E; Wed, 6 Nov 2019 22:51:05 -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=1573109466; x=1604645466; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cBRQ/3vFbCwYYlVIEThsJ15egkt2BUV1U0VKdaUL3Bk=; b=jWpb5GSfu90eNcVMW1knembglhQNTI40fG3M6dA7lzXN3SHYGNzPA8sy enniAiGf/Kr5OS7oLKyK19+wnpn7jNBLCcWJfB4BcLlFGuI/2PCMt7TvO 9LIy9jMphn66m3Ba5PrSAX4O6bnGF2L90Aln5cfNM2qAMHHV+w+/YLSCx jm+82+zvKc6cyt+y+btHB/FIqEWCfdTa9EV3oKTxyrKDktWf9UvJCrUMS uaOx+NQVwxoyVho/xr42iUNEjPq5Z4fFugjzVNkpletGsvSQn0tDwRvmM XmQ+U+ISq1p+mdCtcCuhnitK5aomBSZZyXCGTvSPAD5tkpXvOxYFq+zun Q==;
X-IronPort-AV: E=Sophos;i="5.68,277,1569240000"; d="scan'208";a="98525334"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing
Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Nov 2019 19:51:03 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 7 Nov 2019 19:51:02 +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, 7 Nov 2019 19:51:02 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, David Schinazi <dschinazi.ietf@gmail.com>, Joe Touch <touch@strayalpha.com>
CC: "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: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVkyCjrwMtocCjZ0izavTli3wJVKd6WcIAgAAVngCAAARbAIABsv2AgAAFtwCAAARPgIAACCuAgAASewCAAaJ3cP//jvOAgAHLw4Q=
Date: Thu, 07 Nov 2019 06:51:02 +0000
Message-ID: <1573109463764.56084@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>
In-Reply-To: <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie>
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/1jnF-mXhfJFNSepq-vuYp_LnZEo>
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, 07 Nov 2019 06:51:09 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:

>In addition, the document is missing any real description of the harmful ways
>in which cleartext headers are being (ab)used today.

That's actually something that's missing in general, not specifically in this
document.  Header encryption seems to be taken as an article of faith, we must
do this because it's something we must do, and yet from long experience with
the two protocols that do header encryption (or at least protection), IPsec
and SSH, for the former all it's produced is endless and ongoing headaches for
devices that need to forward/route/manage IPsec traffic, and for the latter
all it's produced is a string of security vulnerabilities.

So what's the sound technical - not religious - argument for header
encryption?  Calling it "abuse" is a purely subjective statement, one person's
abuse is another's essential functionality.  One big example of this DNS
manipulation to implement captive portals, which the DNSSEC folks I've talked
to regard as anathema but without which maybe 90% [figure totally invented] of
public WiFi won't work.  So to the DNSSEC fans it's abuse, to pretty much
everyone else except a few DNSSEC fans it's fine because they want public WiFi
to work for them.

In particular for header encryption there have been at least two dozen papers
published, and many commercial products created, that bypass encryption to do
fairly extensive traffic analysis *of encrypted traffic*, encrypted headers or
no.  So on the one hand we've got real-world experience with two protocols
that do header encryption/protection which has yielded endless problems
(IPsec) and security vulns (SSH), and on the other hand we've got what seems
to be a faith-based belief in something that numerous academic papers have
shown doesn't provide the service it claims to.

Where's the technical argument for header encryption, backed by actual
research showing that it's effective, and that the benefits outweigh the
disadvantages?

Peter.