last call Feedback for Opportunistic Security for HTTP (Experimental)

Patrick McManus <pmcmanus@mozilla.com> Wed, 07 September 2016 17:27 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7855112B47B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 7 Sep 2016 10:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.427
X-Spam-Level:
X-Spam-Status: No, score=-8.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 RvyLDiaZ-Z4t for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 7 Sep 2016 10:27:26 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CFF12B3F6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 7 Sep 2016 10:27:26 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bhgZE-0002tZ-K5 for ietf-http-wg-dist@listhub.w3.org; Wed, 07 Sep 2016 17:23:20 +0000
Resent-Date: Wed, 07 Sep 2016 17:23:20 +0000
Resent-Message-Id: <E1bhgZE-0002tZ-K5@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <pmcmanus@mozilla.com>) id 1bhgYz-0002qA-LD for ietf-http-wg@listhub.w3.org; Wed, 07 Sep 2016 17:23:05 +0000
Received: from www.ducksong.com ([192.155.95.102] helo=linode64.ducksong.com) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from <pmcmanus@mozilla.com>) id 1bhgYw-0000wZ-JN for ietf-http-wg@w3.org; Wed, 07 Sep 2016 17:23:04 +0000
Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by linode64.ducksong.com (Postfix) with ESMTPSA id 408FC3A01B for <ietf-http-wg@w3.org>; Wed, 7 Sep 2016 13:22:29 -0400 (EDT)
Received: by mail-it0-f54.google.com with SMTP id e124so209853069ith.0 for <ietf-http-wg@w3.org>; Wed, 07 Sep 2016 10:22:29 -0700 (PDT)
X-Gm-Message-State: AE9vXwNbwe4LfPReWVZ+HOuRJyOFQ6ZMLPR+HN+CkkL92+FpxRMrbpYN4Fv3iKsXV3sZu3u7J6qDS9aih5wo5A==
X-Received: by 10.36.227.77 with SMTP id d74mr7763113ith.75.1473268948780; Wed, 07 Sep 2016 10:22:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.148.50 with HTTP; Wed, 7 Sep 2016 10:22:28 -0700 (PDT)
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 7 Sep 2016 13:22:28 -0400
X-Gmail-Original-Message-ID: <CAOdDvNpmNB2b56oJJHucv+q_MxSW4POdVMzXXyN2X6bZHJogiw@mail.gmail.com>
Message-ID: <CAOdDvNpmNB2b56oJJHucv+q_MxSW4POdVMzXXyN2X6bZHJogiw@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=94eb2c111d0659d151053bee280a
Received-SPF: softfail client-ip=192.155.95.102; envelope-from=pmcmanus@mozilla.com; helo=linode64.ducksong.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-2.597, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=2.397, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bhgYw-0000wZ-JN 5f270bf8ccaed2c0a8deacf72c1b644f
X-Original-To: ietf-http-wg@w3.org
Subject: last call Feedback for Opportunistic Security for HTTP (Experimental)
Archived-At: <http://www.w3.org/mid/CAOdDvNpmNB2b56oJJHucv+q_MxSW4POdVMzXXyN2X6bZHJogiw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32381
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi all - Firefox Implementer Hat on here.

Nick @cloudflare and I have been working on implementing the
httpwg.org/http-extensions/opsec.html - 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