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.
- [tsvwg] Comments on draft-ietf-tsvwg-transport-en… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Eric Rescorla
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Kathleen Moriarty
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Frode Kileng
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Colin Perkins
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Stephen Farrell
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Colin Perkins
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Phillip Hallam-Baker
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Phillip Hallam-Baker
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Kathleen Moriarty
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann