2.2. Interaction with "https" URIs | Re: Op-sec simplification

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Tue, 01 November 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 5BE13129508 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 1 Nov 2016 10:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 Zan7pQwMvq2G for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 1 Nov 2016 10:27:01 -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 566D912947C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 1 Nov 2016 10:27:00 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c1cln-0000fG-95 for ietf-http-wg-dist@listhub.w3.org; Tue, 01 Nov 2016 17:22:43 +0000
Resent-Date: Tue, 01 Nov 2016 17:22:43 +0000
Resent-Message-Id: <E1c1cln-0000fG-95@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <khurtta@welho.com>) id 1c1clg-0000cr-QH for ietf-http-wg@listhub.w3.org; Tue, 01 Nov 2016 17:22:36 +0000
Received: from welho-filter1.welho.com ([83.102.41.23]) by titan.w3.org with esmtp (Exim 4.84_2) (envelope-from <khurtta@welho.com>) id 1c1cla-0000sR-Ex for ietf-http-wg@w3.org; Tue, 01 Nov 2016 17:22:31 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id BE19F12310; Tue, 1 Nov 2016 19:22:02 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id D5NPbElnaYAR; Tue, 1 Nov 2016 19:22:02 +0200 (EET)
Received: from hurtta09lk.keh.iki.fi (89-27-35-245.bb.dnainternet.fi [89.27.35.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPS id 3CA0B27B; Tue, 1 Nov 2016 19:22:02 +0200 (EET)
In-Reply-To: <20161031053239.E9C6D12F5D@welho-filter3.welho.com>
References: <20161031053239.E9C6D12F5D@welho-filter3.welho.com>
To: HTTP working group mailing list <ietf-http-wg@w3.org>
Date: Tue, 1 Nov 2016 19:22:02 +0200 (EET)
Sender: hurtta@hurtta09lk.keh.iki.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Martin Thomson <martin.thomson@gmail.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha43+]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20161101172202.BE19F12310@welho-filter1.welho.com>
Received-SPF: none client-ip=83.102.41.23; envelope-from=khurtta@welho.com; helo=welho-filter1.welho.com
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=0.377, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.505, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1c1cla-0000sR-Ex 82438c2aa1f206a7715f8c6411a0d1c1
X-Original-To: ietf-http-wg@w3.org
Subject: 2.2. Interaction with "https" URIs | Re: Op-sec simplification
Archived-At: <http://www.w3.org/mid/20161101172202.BE19F12310@welho-filter1.welho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32789
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>

> | https://github.com/httpwg/http-extensions/pull/254
> | 
> | The main changes:
> | 
> |  - the .well-known resource is a flat list of origins
> 
> ( no comment about that yet. )
> 

On earlier version there was concern that if
same connection was used both on "http" 
and "https" scheme then these are
confused by server.

Therefore there was requirement that clients must 
not send "http" requests on a connection that would
ordinarily be used for "https" requests.

There was  "mixed-scheme" flag what disabled that
requirement.

Now there is no that requirement:

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-08#section-2.2

| 2.2.  Interaction with "https" URIs
|
|   When using alternative services, requests for resources identified by
|   both "http" and "https" URIs might use the same connection, because
|   HTTP/2 permits requests for multiple origins on the same connection.
|   Because of the potential for server confusion about the scheme of
|   requests (see Section 4.4), clients MUST NOT send "http" requests on
|   a connection prior to successfully retrieving a valid http-
|   opportunistic resource that contains the origin (see Section 2.3).
|   The primary purpose of this check is to provide a client with some
|   assurance that a server understands this specification and has taken
|   steps to avoid being confused about request scheme.

What is wanted ?  Options

	• No concern; that check that http://{...}/.well-known/http-opportunistic
          succeed tells enough that there is no confusion

        • Forbid using same connection for "http" requests
	  which would ordinarily be used for "https" requests.

	• Forbid using same connection for "http" requests
          which would ordinarily be used for "https" requests
	  but allow it if there is "mixed-scheme" -member (or
	  some other flag).

        • Forbid using same connection for "http" requests
	  which would ordinarily be used for "https" requests
	  unless same connection which was tested
	  for http://{...}/.well-known/http-opportunistic
	  are also after that tested:

		∘ That https requests for /.well-known/http-opportunistic
		  on same host {...} does not return same object

		∘ Note that if that test fails, then that connection
		  is no longer be good for http requests either.
		
/ Kari Hurtta