Re: [perpass] TLS discussion

"Learmonth, Iain Ross" <iain.learmonth.09@aberdeen.ac.uk> Mon, 18 November 2013 09:14 UTC

Return-Path: <iain.learmonth.09@aberdeen.ac.uk>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDD811E8126 for <perpass@ietfa.amsl.com>; Mon, 18 Nov 2013 01:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.363
X-Spam-Level:
X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGfmnQKskyhx for <perpass@ietfa.amsl.com>; Mon, 18 Nov 2013 01:13:57 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0010.outbound.protection.outlook.com [213.199.154.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9EF11E81D7 for <perpass@ietf.org>; Mon, 18 Nov 2013 01:13:12 -0800 (PST)
Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com (10.141.2.151) by DB3PR01MB156.eurprd01.prod.exchangelabs.com (10.141.2.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 09:13:06 +0000
Received: from DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) by DB3PR01MB153.eurprd01.prod.exchangelabs.com ([169.254.11.235]) with mapi id 15.00.0820.005; Mon, 18 Nov 2013 09:13:05 +0000
From: "Learmonth, Iain Ross" <iain.learmonth.09@aberdeen.ac.uk>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Phillip Hallam-Baker <hallam@gmail.com>
Thread-Topic: [perpass] TLS discussion
Thread-Index: AQHO5D05NIqt6GZwAU2CtRejr61+HA==
Date: Mon, 18 Nov 2013 09:13:05 +0000
Message-ID: <7801df6558344b67a684933d4776e294@DB3PR01MB153.eurprd01.prod.exchangelabs.com>
References: <CAMm+Lwg-AF9fZ5=f5W8JDmiCe=U7Uyxso_bdHGaQhddsQ+aGaw@mail.gmail.com>, <5288E344.1020008@cs.tcd.ie>
In-Reply-To: <5288E344.1020008@cs.tcd.ie>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:630:241:204:bd5a:ff16:2b2c:8c50]
x-forefront-prvs: 00342DD5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51444003)(77096001)(56816003)(81342001)(69226001)(47736001)(49866001)(83072001)(50986001)(47976001)(4396001)(74316001)(74662001)(47446002)(74502001)(74482001)(31966008)(74366001)(76796001)(76786001)(33646001)(46102001)(74876001)(15975445006)(81816001)(81686001)(77982001)(59766001)(56776001)(54316002)(76482001)(85306002)(80976001)(83322001)(19580395003)(74706001)(54356001)(65816001)(80022001)(53806001)(87936001)(2656002)(81542001)(51856001)(79102001)(87266001)(63696002)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR01MB156; H:DB3PR01MB153.eurprd01.prod.exchangelabs.com; CLIP:2001:630:241:204:bd5a:ff16:2b2c:8c50; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: aberdeen.ac.uk
Cc: perpass <perpass@ietf.org>
Subject: Re: [perpass] TLS discussion
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2013 09:14:15 -0000

> Other foo/tls protocols will also soon have a separate venue [3]
> and we have a TLS working group. So I see little left to discuss
> about TLS on this list to be honest.

> [3] https://datatracker.ietf.org/doc/charter-ietf-uta/

I agree that the HTTP/TLS discussion should be moved to the uta (Using TLS in Applications) mailing list, when one exists, with regard to authentication. It protects far more against active attacks and this list is about preventing passive mass monitoring being useful.

I think that the discussion relating to the use of TLS for encryption, its effect on proxies and CDNs, and the fact that CDNs are a privacy issue still need discussion here and are relevant to this list.

The main question: are there times when we would ever want HTTP traffic to not be encrypted?
The secondary question is: how does the trust model for CDNs be improved? I don't believe that third-party CDNs that do caching and have access to private information are a good idea. Maybe we can come up with some best practices like only proxy static content but directly contact for dynamic content that could contain private information and declaring in the cert that you're contacting a CDN instead of the actual site? But then there are no guarantees that people are following them.

Iain.