RE: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Mike Bishop <> Wed, 05 October 2016 17:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9525E129717 for <>; Wed, 5 Oct 2016 10:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.017
X-Spam-Status: No, score=-10.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n7sLMx3YRRJ7 for <>; Wed, 5 Oct 2016 10:35:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8BDC1293DC for <>; Wed, 5 Oct 2016 10:35:15 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1brq08-00083v-Ur for; Wed, 05 Oct 2016 17:29:05 +0000
Resent-Date: Wed, 05 Oct 2016 17:29:04 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1brq03-00082n-Iq for; Wed, 05 Oct 2016 17:28:59 +0000
Received: from ([] by with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1brq01-0006Kk-Ap for; Wed, 05 Oct 2016 17:28:58 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CTHPG7zVlGALxncbZDn2q3bmkWUaDA182fnbMmcrjmE=; b=LOsHPBmFABOSy/ErZLu74SM0mlTeWw8a1vkfEOf3900Z7k1lrNcs6jQ26A4q2l2+meZX7heMxnAUpeyicW/BROOj4AgjjbEEhNxXDoxik6OGRekd3aEICJrUfP+Jqr008Legs7dhCaBXc/QhqFLENOAI7ekqXA29svsymgpZkdE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 17:28:21 +0000
Received: from ([]) by ([]) with mapi id 15.01.0649.024; Wed, 5 Oct 2016 17:28:21 +0000
From: Mike Bishop <>
To: Kari Hurtta <>, Martin Thomson <>
CC: Patrick McManus <>, HTTP working group mailing list <>
Thread-Topic: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Date: Wed, 05 Oct 2016 17:28:20 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:f::500]
x-ms-office365-filtering-correlation-id: 36661e7e-8940-4b3d-de2f-08d3ed4500b9
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:NRdllL20ihBOFprX2hlVRnJ6LMoB7neQAOs7dSHt/2a/JYzbKDSfn6bjeOBLc4ySJ/1sPvGK+NvK9YKqMhJpKy3y7XSVPq6ZKWfyexJrGJSW56QfN5R3ClQlEbf+ffW55flDTGaA/ApgCwgwZ64PRJVJ5GQh8RECH3uIDokX/YXnBPf2fvjc4/7XlyVt1WPrAVGR76y1Zhfz9aqp79R2dcrX0Y4JG8CAyZvKLxvyXHtRWj/7vdmJVuwDp1xwbaJ7mNyNRet6F46j3SLw2O/tifMaz7VgoOwnCa3DUBp0bdBkh0TOwvum3ubx5CqbuSzLPWbjEvkeNNiXEpjvpTIxcQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2708;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708;
x-forefront-prvs: 008663486A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(377454003)(13464003)(199003)(3280700002)(87936001)(102836003)(6116002)(8936002)(86362001)(8990500004)(5005710100001)(3660700001)(8676002)(19580405001)(586003)(10090500001)(86612001)(2906002)(4326007)(10290500002)(10400500002)(11100500001)(19580395003)(2900100001)(92566002)(19625305001)(587094005)(93886004)(305945005)(122556002)(97736004)(16601075003)(7846002)(101416001)(15975445007)(33656002)(9686002)(5002640100001)(81166006)(7696004)(81156014)(7736002)(68736007)(77096005)(105586002)(230783001)(5660300001)(5001770100001)(74316002)(189998001)(99286002)(54356999)(76176999)(2950100002)(50986999)(106116001)(106356001)(76576001)(3826002)(376185003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 17:28:20.8788 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-2.457, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1brq01-0006Kk-Ap c1d9154b34fef9f640865dd32c1bdbe3
Subject: RE: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32490
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I'm having trouble envisioning the scenario where you need to split this by origin, though.  Our concerns here are about server implementations that ignore the scheme component and simply rely on the incoming port to provide that information, right?.  That means you need to get that information on a port-by-port (i.e. server/connection) basis.  Is there a scenario where is capable of parsing mixed-scheme requests for one origin, but blind to it for another?  Here are the cases I can think of:

  - Actual server with multiple origins:  It may or may not be configured to *serve* http:// scheme for all origins from that port, but that's indicated by the Alt-Svc headers pointing to it.  Mistaken requests would get a 421.
  - TLS-terminating load balancer:  The connection inside TLS will still reach a single back-end server, so see previous item.
  - HTTP reverse proxy:  The sites behind it may indeed have different capabilities, but that's strictly a function of how the reverse proxy obtains the resources, not something the client needs to validate.

As for moving forward with this, I think it depends on just what we're trying to validate.  Let's agree on the question before we argue about the answer.  Is it:

  - This host is authorized to serve the content for  That's RFC 7838 -- we're done.
  - This host can serve the content for and is smart enough not to get confused when scheme and port don't match?  Again, that's RFC 7838 ("mitigate ... by refraining from advertising alternative services for insecure schemes.").  But if you want to enable clients to double-check the origin administrators, let the alternative declare that it's scheme-aware, whether by existence of a .w-k resource or a connection setting.
  - This host can serve content for both *and* *and* on the same connection without confusing them all?  That seems to be implied by the previous one.
  - This host *consents* to serve  Seems implicit in responding to requests.  What does anyone gain by checking before sending requests versus trying the requests and maybe getting 421s?

Basically, we've simplified this greatly, and I like that.  But we've simplified it so much that I'm no longer clear what problem we have left to solve. Can someone ELI5?

-----Original Message-----
From: [] On Behalf Of Kari Hurtta
Sent: Wednesday, October 5, 2016 9:17 AM
To: Martin Thomson <>
Cc: Kari Hurtta <>; Patrick McManus <>; Mike Bishop <>; HTTP working group mailing list <>
Subject: Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Martin Thomson <>: (Wed Oct  5 17:07:16 2016)
> On 6 October 2016 at 00:36, Kari Hurtta <> wrote:
> >> >> "tls-ports"  should perhaps now be "mixed-scheme-listeners"
> >> >> giving [ "alternative-server:port" ].
> >
> > because should we really say that particular alternative server / 
> > port combination for given origin supports http: -scheme over TLS.
> I interpreted that as:
>   { "": {
>       "mixed-scheme-listeners": [ "", "" ]
>     },
>     "" { ... }
>   }

> This is saying that "" is served (in addition to the 
> cleartext version) on those alternatives.

Or actually:

	If Alt-Svc -header field gives this alternative, then
	this alternative (for that origin) is safe to use
	for http: -scheme via TLS (assuming that thhis
	alternative service returns same /.well-known/http-opportunistic
	responce that origin).

〔removed 〕

> > But also for particular origin there may be several alternative 
> > servers which are not equal.
> Not sure that I follow: are you suggesting that the .wk resource would 
> advertise the other origins, or that we need some sort of additional 
> protection?

/.well-known/http-opportunistic list there origins which share same /.well-known/http-opportunistic -file or resource.

For particular origin /.well-known/http-opportunistic list these potential alternatice service name and port, which are safe for
http: -scheme over TLS.

This is additional protection.  SETTINGS_MIXED_SCHEME_PERMITTED take account that all alternatice services for given origin are not good for http: -scheme over TLS, but it does not take account that connection is shared with several origins.

If /.well-known/http-opportunistic list only origins, then it does not take account that all alternative services are not hood for http: -scheme over TLS.

( I assume that alternative services are good for
  https: -scheme and they are valid certificate
  and some subset of url -path namespace is
  shared between http: and https: -scheme. 
  But /login is not good for http: -scheme.

/ Kari Hurtta