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

Mike Bishop <> Thu, 06 October 2016 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60406129717 for <>; Thu, 6 Oct 2016 11:17:04 -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 tBdsAIytETP5 for <>; Thu, 6 Oct 2016 11:17:02 -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 3D2CE120726 for <>; Thu, 6 Oct 2016 11:17:02 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bsDAG-00060X-BU for; Thu, 06 Oct 2016 18:13:04 +0000
Resent-Date: Thu, 06 Oct 2016 18:13: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 1bsDA9-0005zm-Rb for; Thu, 06 Oct 2016 18:12:57 +0000
Received: from ([] by with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bsDA6-000755-2y for; Thu, 06 Oct 2016 18:12:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PVkmxe9bzyuRduEtrEwDJOiBcHKEBZeTOAEsZ6878Xk=; b=O4NobvxjSOeb6NYDb+bBLJVIMNvMrEkXwZV07OKKIqmCj+K/kIAmMZ6XIb7CXrHsOzdMbK2Qp7CMQwPygfe/ezpjWGc38fbHyd4LRJQKUngXfygnQXroCRLUBnaV4LxAVvYeW91BiOZM6R9vR2VqMjJc6Al1UOoXCe5qn9NL724=
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; Thu, 6 Oct 2016 18:12:25 +0000
Received: from ([]) by ([]) with mapi id 15.01.0649.024; Thu, 6 Oct 2016 18:12:25 +0000
From: Mike Bishop <>
To: Martin Thomson <>
CC: Kari Hurtta <>, 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: Thu, 06 Oct 2016 18:12:24 +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: 902cd0c6-12ae-4b8d-429c-08d3ee14531c
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:BZzd2yccHszBnP9BnAcLDmFtNJLurKi1pcIWx2uCVUA9UL+qvKZlNfxIASPYMBoHbkV6CcxfAIiS+Lz59jNTdTxk0YX0jx/yJn+v94r0xwEkA7B26fzfuY1e7QO8N07gA85sOubDf4Bl04D/i4wBm6N/WGV/1kz0+9Y0ype3purfM90bXht//Cn1L38sEkGh9LlyAo1egokh+JWASirzxAnYTattcUSJOso9+4BfanaphAhmc9XVS46yXpOwBQo5c+r0RxnJ4vlAb3Vyd3FFnH/p5rqTL5LXZ6iNS+79HzHHJFkXREtn2TKp9csVmSxX8a3CLUMKfHtNwx9q9up35Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2708;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708;
x-forefront-prvs: 00872B689F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(13464003)(189002)(24454002)(51444003)(101416001)(7846002)(16601075003)(97736004)(122556002)(81156014)(9686002)(33656002)(5002640100001)(54356999)(81166006)(2900100001)(15975445007)(7696004)(92566002)(7736002)(561944003)(305945005)(93886004)(2950100002)(189998001)(76576001)(76176999)(99286002)(74316002)(106356001)(587094005)(106116001)(50986999)(5660300001)(105586002)(77096005)(230783001)(68736007)(110136003)(8990500004)(6116002)(6916009)(8676002)(3660700001)(3280700002)(87936001)(86612001)(102836003)(10290500002)(4326007)(2906002)(10400500002)(11100500001)(19580405001)(10090500001)(5005710100001)(586003)(19580395003)(86362001)(8936002)(3826002)(376185003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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: 06 Oct 2016 18:12:24.9818 (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.461, 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: 1bsDA6-000755-2y f068b2ba604108cec7e6a8aa6f0bac4d
Subject: RE: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/32507
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Okay, so we are basically trying to backfill a possible administrative mistake by verifying that the server processes scheme as part of origin.  So an administrator MUST BUT WE KNOW YOU WON'T only put this resource in place if their server is properly configured to handle a scheme inconsistent with the port.  After they already have to opt in by sending the Alt-Svc header on the origin in the first place.  I'm lacking confidence that this check actually assures anything except that the administrator wants it to work, and we already know that from the Alt-Svc header.

If we want to *validate* that the server is handling scheme properly, then we need to have different content at http:// and https:// and check that we get the right one over the right scheme.  If an identical resource is present on both schemes, retrieving it doesn't prove anything, and I continue to doubt that it tells us anything about administrative intent that we don't already know from the Alt-Svc header being emitted.

What if http://.../.w-k/h-o MUST exist (200) and https:// .../.w-k/h-o MUST NOT exist (404)?  If a client checks both of those things, it has actually proven scheme handling rather than just asked the server to promise.

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

I'll try, but it might be ELI15...

On 6 October 2016 at 04:28, Mike Bishop <> wrote:
> 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?

A client learns that a server has a "secure" alternative.  This implies that clients can send "not-secure" requests to a "secure"

The client wants to know that this alternative understands what it means when it sends a "not-secure" request to that server.  This is because some "secure" servers can be confused by a "not-secure"
request. They might think that it is "secure" and do the wrong thing.

We need to find a way to ask the "secure" server if it is OK with getting "not-secure" requests.

>   - This host is authorized to serve the content for  That's RFC 7838 -- we're done.

I wish.

>   - 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.

It's hard to know whether a server is confused just by making regular requests.

>   - 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.

I think that Kari was hinting at a problem where a load balancer terminates TLS and then routes based on the Host header alone.  The back-end servers aren't all equally capable of distinguishing between "secure" and "not-secure".

That suggests to me that you probably want proof positive for all origins separately, as we discussed.

>   - 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?

See above regarding confusion.  Just providing a response isn't enough.


Here's my concrete proposal (as I made earlier):

Before using a secure alternative for an http:// origin, a client MUST first request /.well-known/http-opportunistic at that origin.  If this resource exists and a not-stale 2xx response is obtained, then requests for the origin MAY be directed toward the secure alternative.
The contents of this resource do not matter.  If multiple http:// origins are coalesced onto the same connection to a secure alternative, a client MUST obtain an http-opportunistic resource from each origin separately.

You might insist on greater proof here (a Content-Location header field would be stronger proof, or you could mandate some format for the response body), but I don't believe that to be necessary.  Once the http-opportunistic resource exists, then we have proof that the server has opted in.

This does mean that in co-hosted situations an audit is recommended to ensure that there are no resources for which there are a) necessary variations between https:// and http:// resources on the same path and
b) confusion might be possible.  The server operator then needs to choose whether to disable http-opportunistic just on the affected origins or to disable the feature entirely.