Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346B61A1AB3 for ; Tue, 10 Feb 2015 17:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4V5TFMDyW5ES for ; Tue, 10 Feb 2015 17:25:45 -0800 (PST) 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 252711A1AB1 for ; Tue, 10 Feb 2015 17:25:44 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from ) id 1YLM0K-0003Vn-HK for ietf-http-wg-dist@listhub.w3.org; Wed, 11 Feb 2015 01:22:12 +0000 Resent-Date: Wed, 11 Feb 2015 01:22:12 +0000 Resent-Message-Id: Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from ) id 1YLM0E-0003V6-TG for ietf-http-wg@listhub.w3.org; Wed, 11 Feb 2015 01:22:06 +0000 Received: from li629-102.members.linode.com ([192.155.95.102] helo=linode64.ducksong.com) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1YLM0D-0002rj-50 for ietf-http-wg@w3.org; Wed, 11 Feb 2015 01:22:06 +0000 Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id 697403A01A for ; Tue, 10 Feb 2015 20:21:42 -0500 (EST) Received: by mail-qc0-f182.google.com with SMTP id x3so453729qcv.13 for ; Tue, 10 Feb 2015 17:21:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.95.179 with SMTP id i48mr56618162qge.4.1423617702068; Tue, 10 Feb 2015 17:21:42 -0800 (PST) Received: by 10.140.91.200 with HTTP; Tue, 10 Feb 2015 17:21:42 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Feb 2015 20:21:42 -0500 Message-ID: From: Patrick McManus To: Patrick McManus Cc: Erik Nygren , HTTP Working Group Content-Type: multipart/alternative; boundary=001a11c16dfc6d89e1050ec5d34c Received-SPF: neutral client-ip=192.155.95.102; envelope-from=pmcmanus@mozilla.com; helo=linode64.ducksong.com X-W3C-Hub-Spam-Status: No, score=-3.6 X-W3C-Hub-Spam-Report: AWL=-2.461, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001 X-W3C-Scan-Sig: maggie.w3.org 1YLM0D-0002rj-50 016f1d4de76cddd2eb89a382a43a9b0a X-Original-To: ietf-http-wg@w3.org Subject: Re: http2 opportunistic security negotiation Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/28803 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --001a11c16dfc6d89e1050ec5d34c Content-Type: text/plain; charset=UTF-8 I guess what I meant, but didn't say, was I don't understand your assertion that this needs to be handled at the TLS layer. This is afterall a typo in the uri - and that's always a problem for routing :) There are lots of existing pure h1 sites that have working http://example.com and an https://example.com that gives a cert warning and then a broken website if you proceed. We can certainly do better than a broken website using http level response codes 3xx or 4xx, and if the possibility of a typo leading to a cert dialog is so painful I would suggest a valid cert might be the right option for such a org.. the usual reasons around why-not-https (3rd party content, referrer) really don't apply strongly to responding to this particular transaction. crazy? On Tue, Feb 10, 2015 at 7:02 PM, Patrick McManus wrote: > What about 421 for https scheme or any h1 on 443? > On Feb 10, 2015 6:14 PM, "Erik Nygren" wrote: > >> The two motivations for OE are to 1) help HTTP/2 deployment for >> HTTP-scheme sites by getting around meddlesome middle-boxes, while 2) also >> providing a tiny bit of protection against pervasive monitoring. In both >> cases, the closer the traffic is to HTTPS traffic (port 443) the more >> likely it is to make it through and work without interference. Both argue >> for using port 443 with a handshake where at least the ClientHello is >> indistinguishable between a true HTTPS request and an OE HTTP request. >> >> The "cleanest" solution would just be to give OE for HTTP/2 its own ALPN >> token such that it is explicitly negotiated where you only send that token >> in your ClientHello. This would help for #1 but is not ideal for #2. On >> the other hand, there are some many attack vectors for #2 that it seems >> more worthwhile to make sure #1 works well while raising the bar a little >> for #2 where possible. >> >> Erik >> >> >> On Tue, Feb 10, 2015 at 5:47 PM, Patrick McManus >> wrote: >> >>> I might be under-thinking this one.... but it occurs to me its possible >>> to not put the tls version of the site on 443 if there is no https:// >>> version of the site.. oe doesn't require a particular port number and 443 >>> seems like the wrong choice if https:// isn't available. too simplistic? >>> >>> On Thu, Feb 5, 2015 at 10:08 AM, Erik Nygren wrote: >>> >>>> While digging further into server-side implementation details of the >>>> current opportunistic security draft, we identified a user experience >>>> problem. In particular, for a site that has Virtual Hosts which are >>>> HTTP-only (ie, there is no valid certificate for them), there is no way in >>>> the current proposal to both support Opportunistic Security (negotiate h2 >>>> for http scheme over TLS without a necessarily valid certificate) without >>>> also giving users accidentally typing in https URIs a certificate mismatch >>>> interstitial they'd be prompted to click through. >>>> >>> >>> >>> >> >> --001a11c16dfc6d89e1050ec5d34c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess what I meant, but didn't say, was I = don't understand your assertion that this needs to be handled at the TL= S layer.

This is afterall a typo in the uri - and that= 9;s always a problem for routing :)

There are lots of existing= pure h1 sites that have working http://exam= ple.com and an https://example.com = that gives a cert warning and then a broken website if you proceed. We can = certainly do better than a broken website using http level response codes 3= xx or 4xx, and if the possibility of a typo leading to a cert dialog is so = painful I would suggest a valid cert might be the right option for such a o= rg.. the usual reasons around why-not-https (3rd party content, referrer) r= eally don't apply strongly to responding to this particular transaction= .

crazy?



On Tue, Feb 10, 2015 at 7:02 PM= , Patrick McManus <pmcmanus@mozilla.com> wrote:

What about 421 for https scheme or = any h1 on 443?

On Feb 10, 2015 6:14 PM, "Erik Nygren"= <erik@nygren.org> wrote:
The two motivations for OE are to 1) help HTTP/2 deployment= for HTTP-scheme sites by getting around meddlesome middle-boxes, while 2) = also providing a tiny bit of protection against pervasive monitoring.=C2=A0= In both cases, the closer the traffic is to HTTPS traffic (port 443) the m= ore likely it is to make it through and work without interference.=C2=A0 Bo= th argue for using port 443 with a handshake where at least the ClientHello= is indistinguishable between a true HTTPS request and an OE HTTP request.<= br>
The "cleanest" solution would just be to give O= E for HTTP/2 its own ALPN token such that it is explicitly negotiated where= you only send that token in your ClientHello.=C2=A0 This would help for #1= but is not ideal for #2.=C2=A0 On the other hand, there are some many atta= ck vectors for #2 that it seems more worthwhile to make sure #1 works well = while raising the bar a little for #2 where possible.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


On Tue, Feb 10, 2015 at 5:47 PM, P= atrick McManus <pmcmanus@mozilla.com> wrote:
I might be under-thinking this one..= .. but it occurs to me its possible to not put the tls version of the site = on 443 if there is no https:// version of the site.. oe doesn't require= a particular port number and 443 seems like the wrong choice if https:// i= sn't available. too simplistic?

On Thu, Feb 5, 2015 at 10:08 AM, Erik Nygr= en <erik@nygren.org> wrote:
While digging further into server-side implementation details of the curre= nt opportunistic security draft, we identified a user experience problem.= =C2=A0 In particular, for a site that has Virtual Hosts which are HTTP-only= (ie, there is no valid certificate for them), there is no way in the curre= nt proposal to both support Opportunistic Security=C2=A0 (negotiate h2 for = http scheme over TLS without a necessarily valid certificate) without also = giving users accidentally typing in https URIs a certificate mismatch inter= stitial they'd be prompted to click through.

=C2=A0


--001a11c16dfc6d89e1050ec5d34c--