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 B41321A1B12 for ; Tue, 10 Feb 2015 16:06:04 -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 intpf1oU5TMy for ; Tue, 10 Feb 2015 16:06:02 -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 B44FE1A1AEC for ; Tue, 10 Feb 2015 16:05:39 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from ) id 1YLKlh-0001OK-1i for ietf-http-wg-dist@listhub.w3.org; Wed, 11 Feb 2015 00:03:01 +0000 Resent-Date: Wed, 11 Feb 2015 00:03:01 +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 1YLKlb-0001Nd-KS for ietf-http-wg@listhub.w3.org; Wed, 11 Feb 2015 00:02:55 +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 1YLKla-0008Vi-Iu for ietf-http-wg@w3.org; Wed, 11 Feb 2015 00:02:55 +0000 Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id 18F6A3A01A for ; Tue, 10 Feb 2015 19:02:33 -0500 (EST) Received: by mail-qa0-f45.google.com with SMTP id j7so234718qaq.4 for ; Tue, 10 Feb 2015 16:02:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.85.9 with SMTP id m9mr55154883qgd.7.1423612952862; Tue, 10 Feb 2015 16:02:32 -0800 (PST) Received: by 10.140.91.200 with HTTP; Tue, 10 Feb 2015 16:02:32 -0800 (PST) Received: by 10.140.91.200 with HTTP; Tue, 10 Feb 2015 16:02:32 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Feb 2015 19:02:32 -0500 Message-ID: From: Patrick McManus To: Erik Nygren Cc: HTTP Working Group Content-Type: multipart/alternative; boundary=001a11c12e965a689d050ec4b80b 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.480, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001 X-W3C-Scan-Sig: maggie.w3.org 1YLKla-0008Vi-Iu 7748643fe10ac5ba24328c3925575760 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/28799 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: --001a11c12e965a689d050ec4b80b Content-Type: text/plain; charset=UTF-8 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. >>> >> >> >> > > --001a11c12e965a689d050ec4b80b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

On Feb 10, 2015 6:14 PM, "Erik Nygren"= <erik@nygren.org> wrote:
Th= e two motivations for OE are to 1) help HTTP/2 deployment for HTTP-scheme s= ites by getting around meddlesome middle-boxes, while 2) also providing a t= iny bit of protection against pervasive monitoring.=C2=A0 In both cases, th= e closer the traffic is to HTTPS traffic (port 443) the more likely it is t= o make it through and work without interference.=C2=A0 Both argue for using= port 443 with a handshake where at least the ClientHello is indistinguisha= ble between a true HTTPS request and an OE HTTP request.

= The "cleanest" solution would just be to give OE for HTTP/2 its o= wn ALPN token such that it is explicitly negotiated where you only send tha= t 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 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.

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


On Tue, Feb 10, 2015 at 5:47 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
I might be under-thinking this one.... but it occurs t= o 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 <erik@nygren.o= rg> wrote:
While digging f= urther into server-side implementation details of the current opportunistic= security draft, we identified a user experience problem.=C2=A0 In particul= ar, 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 bot= h support Opportunistic Security=C2=A0 (negotiate h2 for http scheme over T= LS without a necessarily valid certificate) without also giving users accid= entally typing in https URIs a certificate mismatch interstitial they'd= be prompted to click through.

=C2=A0

--001a11c12e965a689d050ec4b80b--