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

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Fri, 04 November 2016 04:28 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 78387129781 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Nov 2016 21:28:43 -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 a12tZvOMLd2I for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Nov 2016 21:28:41 -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 A0E4F1296EF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 3 Nov 2016 21:28:33 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c2W3C-0003Tr-5v for ietf-http-wg-dist@listhub.w3.org; Fri, 04 Nov 2016 04:24:22 +0000
Resent-Date: Fri, 04 Nov 2016 04:24:22 +0000
Resent-Message-Id: <E1c2W3C-0003Tr-5v@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <hurtta@siilo.fmi.fi>) id 1c2W35-0003So-8Y for ietf-http-wg@listhub.w3.org; Fri, 04 Nov 2016 04:24:15 +0000
Received: from smtpvgate.fmi.fi ([193.166.223.36]) by mimas.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <hurtta@siilo.fmi.fi>) id 1c2W2y-0007L4-Ml for ietf-http-wg@w3.org; Fri, 04 Nov 2016 04:24:10 +0000
Received: from basaari.fmi.fi (basaari.fmi.fi [193.166.211.14]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id uA44NbHP029168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Nov 2016 06:23:38 +0200
Received: from shell.siilo.fmi.fi by basaari.fmi.fi with ESMTP id uA44NbKJ011164 ; Fri, 4 Nov 2016 06:23:37 +0200
Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id uA44NbqU009785 ; Fri, 4 Nov 2016 06:23:37 +0200
Received: by shell.siilo.fmi.fi id uA44Na1e009784; Fri, 4 Nov 2016 06:23:36 +0200
Message-Id: <201611040423.uA44Na1e009784@shell.siilo.fmi.fi>
In-Reply-To: <CABkgnnUanWhMncsp2XDZgwXjCn7K7+39mvmXWZKFjMDHw6UwOA@mail.gmail.com>
References: <20161031053239.E9C6D12F5D@welho-filter3.welho.com> <20161101172202.BE19F12310@welho-filter1.welho.com> <CABkgnnWhcp_tVx9M9FTOdSF-U5EoAzdNNVZaYzjdxUGhHydX7w@mail.gmail.com> <201611020548.uA25m4Wm026906@shell.siilo.fmi.fi> <CABkgnnUL+AJEi=92K95f22vrx17Rmm0j1rEahhwu-my3DPcEwA@mail.gmail.com> <CAKC-DJiGp3g26nDZJg4tor4B7-om+BZZp=Hgp4JXNik_ibDPkQ@mail.gmail.com> <CABkgnnUanWhMncsp2XDZgwXjCn7K7+39mvmXWZKFjMDHw6UwOA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 4 Nov 2016 06:23:36 +0200 (EET)
Sender: hurtta@siilo.fmi.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Erik Nygren <erik@nygren.org>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, 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: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20161104/48446/01
X-Filter: smtpVgate.fmi.fi: ID 48453/01, 1 parts scanned for known viruses
X-Filter: basaari.fmi.fi: ID 153955/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Fri, 04 Nov 2016 06:23:38 +0200 (EET)
Received-SPF: none client-ip=193.166.223.36; envelope-from=hurtta@siilo.fmi.fi; helo=smtpVgate.fmi.fi
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=0.106, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.305, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c2W2y-0007L4-Ml ae5aeb96859944889a492ce0975ac8fb
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 2.2. Interaction with "https" URIs | Re: Op-sec simplification
Archived-At: <http://www.w3.org/mid/201611040423.uA44Na1e009784@shell.siilo.fmi.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32847
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>

Martin Thomson <martin.thomson@gmail.com>om>: (Fri Nov  4 02:16:35 2016)
> On 3 November 2016 at 07:02, Erik Nygren <erik@nygren.org> wrote:
> > An example of why this could be bad would be a CDN server that terminates
> > both HTTP and HTTPS over TLS but demuxes them such that HTTPS requires TLS
> > to content origin but HTTP is allowed to go cleartext to content origin.
> > When a single TLS connection demuxes to a mixture of TLS and cleartext
> > traffic, this feels like asking for increased trouble and attack surfaces.
> > Prohibiting mixed-scheme on the incoming connection makes this feel much
> > safer.
> 
> I am almost inclined to say that you don't get to use the feature if
> you are concerned about this causing issues of that sort.  Or, as some
> of us have discussed, a new h2 setting that prohibits coalescing might
> be a simpler option.
> 
> Kari's solution works, though it opens other possibilities, and I'm
> concerned we're off down the rabbit hole again:
> 
> { "http://...": "mixed-scheme", --> open season
>   "http://...": "single-scheme", --> only one scheme per connection
>   "http://...": "dedicated-connection" } --> only one origin per connection

Only one origin per connection ("dedicated-connection") is 
better to use some other mechanism because that look 
someting which is not limited to Opportunistic HTTP Security.
It looks like something which is wanted also for "https".

"single-scheme" looks like rougly same than "distinct-connection" 
on my suggestion.  "distinct-connection" was 'own connection for 
Opportunistic HTTP Security' and that imply that only scheme used 
on that connection is "http". 

And "Opportunistic HTTP Security" really does not want say
usage of other connections, which are not used by it, so 
"single-scheme" does not say more than "distinct-connection".

/ Kari Hurtta