Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 03 February 2014 17:51 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3D61A01DB for <uta@ietfa.amsl.com>; Mon, 3 Feb 2014 09:51:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 0uMbKQe0IsGd for <uta@ietfa.amsl.com>; Mon, 3 Feb 2014 09:51:19 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1E64C1A017E for <uta@ietf.org>; Mon, 3 Feb 2014 09:51:19 -0800 (PST)
Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id B2972F984 for <uta@ietf.org>; Mon, 3 Feb 2014 12:51:17 -0500 (EST)
Message-ID: <52EFD713.3080303@fifthhorseman.net>
Date: Mon, 03 Feb 2014 12:51:15 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0
MIME-Version: 1.0
To: uta@ietf.org
References: <20140203045910.9714.53880.idtracker@ietfa.amsl.com> <B8691415-07F3-4081-8247-E103A60E5CF0@vpnc.org>
In-Reply-To: <B8691415-07F3-4081-8247-E103A60E5CF0@vpnc.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="vaQkTMulslugjQL1VbTsFqF4b8xNABfSw"
Subject: Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 17:51:20 -0000
On 02/03/2014 12:03 AM, Paul Hoffman wrote: > Greetings again. One of the deliverables in our charter is: > > - Consider, and possibly define, a standard way for an application > client and server to use unauthenticated encryption through TLS > when server and/or client authentication cannot be achieved. > > I think that wording was sloppy, and would like the WG to come up with a clear definition of what it is we want application protocols to possibly support in order to thwart pervasive monitoring. I put together my ideas in a very short draft. > > If folks like the idea of this definition, I think it would be appropriate for a WG document. Thanks for framing this, Paul. I think it's clear that the "Opportunistic" mode you describe is superior to leaving everything in the clear; and i appreciate your draft's insistence that it not present itself to the user as a well-authenticated connection, due to the difference in vulnerability to an active attacker. I understand that the purpose of the draft is not to document technical mechanisms for doing this opportunistic encryption, but i can't help trying to think through how it would work for HTTPS (i note that SMTP already has a mechanism, more people just need to turn it on). It occurs to me that one possibility is that user agents could just enable the use of the HTTP upgrade mechanism described in RFC 2817. I don't know of any major browser that does this, or of any common web server that implements it either. Perhaps this means it's ripe for use in this context? The RFC even specifically leaves open the level of security expected from such an upgraded connection: https://tools.ietf.org/html/rfc2817#section-8.1 I'm imagining a WWW user agent that would have something like the following logic: ----------------- 0) store two tables of web sites with recent refresh times, both initially empty, named "UPGRADABLE" and "NOUPGRADE". 1) for each new http:// connection to a site not in either table, include the "Upgrade: TLS/1.2\r\nConnection: Upgrade" header. 1a) if the site offers an upgrade, negotiate TLS on that link (without requiring server certificates to match). If the TLS negotiation succeeds, store the hostname in UPGRADABLE with the current timestamp; if it fails, store the site in NOUPGRADE with the current timestamp. 1b) if the site does not offer an upgrade, do not store the site in either table, and continue with the cleartext connection. 2) for each new http:// connection to a site in NOUPGRADE, do not include the Upgrade: TLS/1.2 header, and do not attempt the upgrade (this avoids a loop to a misbehaving server) 3) for each new http:// connection to a site in UPGRADABLE, do not emit the normal HTTP request in the first place, but start with an OPTIONS * HTTP/1.1 request, the "Mandatory Upgrade" described here: https://tools.ietf.org/html/rfc2817#section-3.2 -- this is to avoid leaking the rest of the HTTP headers. 3a) if the TLS negotiation succeeds, update the timestamp for the site in UPGRADABLE 3b) if the TLS negotiation fails, remove the site from UPGRADABLE and restart the connection. 4) at regular intervals, clear all UPGRADABLE and NOUPGRADE table entries older than some fixed time window (1 week?) ----------------- Obviously, web servers shouldn't use the above logic to promote "normal" https -- for that, web servers should use the standard HTTP 301 Moved Permanently (Location: https://…), combined with Strict-Transport-Security header on the subsequent https response. Does the above logic seem plausible? I worry a bit about browser fingerprinting and history leaking that might result from the UPGRADABLE and NOUPGRADE tables, but it doesn't seem significantly worse than many existing pieces of data retained by browsers about the sites they visit, and i think it would provide a real gain in privacy against ubiquitous passive monitoring. Do other folks have concerns or suggestions or other ways we could implement this for HTTP? --dkg
- [Uta] Proposed definition of opportunistic encryp… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Olle E. Johansson
- Re: [Uta] Proposed definition of opportunistic en… Stephen Farrell
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Leif Johansson
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Stephen Farrell
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman