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

Nick Sullivan <> Wed, 07 September 2016 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 835EF12B57C for <>; Wed, 7 Sep 2016 10:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.527
X-Spam-Status: No, score=-8.527 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.001, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IpvLul47idAh for <>; Wed, 7 Sep 2016 10:54:50 -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 EDB0412B573 for <>; Wed, 7 Sep 2016 10:54:49 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bhgym-0002Yw-Hc for; Wed, 07 Sep 2016 17:49:44 +0000
Resent-Date: Wed, 07 Sep 2016 17:49:44 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bhgya-0002Vl-LH for; Wed, 07 Sep 2016 17:49:32 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bhgyY-0006SB-OQ for; Wed, 07 Sep 2016 17:49:32 +0000
Received: by with SMTP id i184so211981942itf.1 for <>; Wed, 07 Sep 2016 10:49:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ygh7uTOYNOerCcI8Ny2NNGwzXidiDGAw3Np617Vq3vY=; b=rlIE211ve5TrcH2jwMhFBCzEvqbQOwI69v96x2bzBXiKGuhu3Co2kaP7jUL3393n/8 USeHJbTeoC9ucPVss6cd7mOjUJecgOwfATTYBXqNrvV/peQ+pIvyj+Qvtexuda2yMqED fbit3yaOOV3UzV6TkH5ynmUsw8z75fUvPF+5e6KAi1kak97iV2UpKIbrvgY+HQp+d+xM LdXOKbv7tGwIMlr7crmoIkU2UpPb8329//B9hamjI92FtjH7F5mMqMCP2TelJ8ywHv+e EO083mvYZDONweuq+mOpQM4kUQhsyriRg0Bp6DSCqZ9CudG7FqaX1rVqijHwnnj2/ybM 55/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ygh7uTOYNOerCcI8Ny2NNGwzXidiDGAw3Np617Vq3vY=; b=aC+/IJOosgjova1vCRK5ivpbfHx9SCr1Re3JZiGAlkJH5enyqXW5MjyNwjHQ9bXaNx iDYbIAzgXcVLYnumOqjqvnNFrc2hE+9+Y9G3E4cZKHs/rxJgxlMFY3+Hclatb6KEXFVH 1Zrx+rXvko2/Tz/rxTDuT5OuFiImmvd3FS4XBoWt+SOAFH4elKRSY19STe8hWJ/SvYeI T/jIPyET6XZrQbubZyLLtUicu5k+Uy6ImWBKMG7dfHsdnKA/SdcALbc4jbs55SU4BO64 I0nIg5Dw5b6n8fb1JGA3MA0qM/Q36jIoTWgmz0MeyKms9teVriqHIZwv6TAMdnTkJtpQ gXMg==
X-Gm-Message-State: AE9vXwM2wXS7S8tgV/rClUHQbjRG9OQNdR05T+uYKGoptI+KxVwH2POZZMjB/0XrzjiJFpJQE6GN3qHoN90UTA==
X-Received: by with SMTP id b14mr8054625itb.29.1473270544675; Wed, 07 Sep 2016 10:49:04 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Nick Sullivan <>
Date: Wed, 07 Sep 2016 17:48:54 +0000
Message-ID: <>
To: Patrick McManus <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary=001a1144b0c4793985053bee87ac
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.3
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=2.397, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bhgyY-0006SB-OQ 8d498501d6e10a4f5c00261e39dd4c29
Subject: Re: last call Feedback for Opportunistic Security for HTTP (Experimental)
Archived-At: <>
X-Mailing-List: <> archive/latest/32383
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I support this change. Requiring certificate validation for opportunistic
security makes it more robust and simplifies the logic around retroactively
applying certificate validation to the .wk if the tls-commit is present.


On Wed, Sep 7, 2016 at 10:28 AM Patrick McManus <>

> 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
> 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