Re: last call Feedback for Opportunistic Security for HTTP (Experimental)

Mark Nottingham <> Wed, 28 September 2016 03:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA4BA12B3BF for <>; Tue, 27 Sep 2016 20:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.237
X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WTnnczOsLC83 for <>; Tue, 27 Sep 2016 20:29:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB4C612B3C0 for <>; Tue, 27 Sep 2016 20:29:03 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bp5UY-0005cU-Sp for; Wed, 28 Sep 2016 03:25:06 +0000
Resent-Date: Wed, 28 Sep 2016 03:25:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bp5UQ-0003lS-W3 for; Wed, 28 Sep 2016 03:24:59 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bp5UO-0003Df-5y for; Wed, 28 Sep 2016 03:24:57 +0000
Received: from [] (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EBCB622E1FA; Tue, 27 Sep 2016 23:24:31 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Wed, 28 Sep 2016 13:24:28 +1000
Cc: HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Patrick McManus <>
X-Mailer: Apple Mail (2.3226)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.3
X-W3C-Hub-Spam-Report: AWL=1.351, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1bp5UO-0003Df-5y f7d930be6f2352e644ca4b10e019bc56
Subject: Re: last call Feedback for Opportunistic Security for HTTP (Experimental)
Archived-At: <>
X-Mailing-List: <> archive/latest/32420
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Early cut here, feedback welcome:

> On 28 Sep. 2016, at 12:48 pm, Mark Nottingham <> wrote:
> It seems like there's support for doing this, at least to the point where we should edit the document so the WG can see what it would look like.
> I'll take a crack at doing that so we can talk about it in Seoul (if not before).
> Cheers,
>> On 8 Sep. 2016, at 3:22 am, Patrick McManus <> wrote:
>> Hi all - Firefox Implementer Hat on here.
>> Nick @cloudflare and I have been working on implementing the - which is in wg last call on the experimental track.
>> Based on that experimental work, I'm going to recommend a few changes to the document before sending to IETF LC. I'll open issues on these too when I get a chance.
>> 1] opportunistic security should require TLS authentication. Any other approach undermines the opt-in mechanism of .wk. As the PKI market has matured to allow truly free and automated certs certificate availability is no longer the chief barrier to https, and so opportunistic security should feel comfortable requiring real authentication. (THERE IS NO PROPOSED CHANGE IN THE SECURITY MODEL - HTTP:// IS STILL HTTP:// AND NOT GRANTED HTTPS:// STATUS AT ALL). The biggest barrier to https:// at this point seems to be mixed content.
>> 2] /.well-known/http-opportunistic should always be required. The current doc is actually a little fuzzy on this, I think by accident. It refers to this as an "additional mechanism" in addition to authentication. But .wk does not really play the same role - it allows the server to opt-in to being an alternate for specific origins on specific ports. So if we're going to use it - we should always use it. (This has no bearing on https:// alt-svc, this is just about http:// as that is all this doc governs).
>> 3] get rid of tls-commit (i.e. the latch to opp sec) as this plays very poorly with alt-svc. The notion of alt-svc has always been that it is a shortcut route (or dns name if your prefer) for the same content as supplied at the default origin. If for any reason you cannot get there, you can always go back to the default origin. All of the machinery around this (validating alternates, etc) can happen transparently and asynchronously in the background until they are ready to be used. A mechanism that requires a characteristic of a route (auth'd TLS) but not the route itself doesn't play well - its far too easy to brick your site for an extended period of time and really ceases to be opportunistic in any meaningful sense. If you're up to managing this, then you're probably up to the fight of running https:// and using HSTS which at least has the benefit of not bringing a whole second technology (alt-svc) into play.
>> Let me know what you think.
>> -Patrick
> --
> Mark Nottingham

Mark Nottingham