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