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

Mike Bishop <Michael.Bishop@microsoft.com> Wed, 05 October 2016 20:01 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 BE4B8129468 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 5 Oct 2016 13:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.017
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 2APquwdqZ2Rm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 5 Oct 2016 13:01:05 -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 035851293F3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 5 Oct 2016 13:01:04 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1brsH0-0002ZZ-Eu for ietf-http-wg-dist@listhub.w3.org; Wed, 05 Oct 2016 19:54:38 +0000
Resent-Date: Wed, 05 Oct 2016 19:54:38 +0000
Resent-Message-Id: <E1brsH0-0002ZZ-Eu@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <Michael.Bishop@microsoft.com>) id 1brsGv-0002X4-FX for ietf-http-wg@listhub.w3.org; Wed, 05 Oct 2016 19:54:33 +0000
Received: from mail-by2nam01on0105.outbound.protection.outlook.com ([104.47.34.105] helo=NAM01-BY2-obe.outbound.protection.outlook.com) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <Michael.Bishop@microsoft.com>) id 1brsGt-0005nt-FB for ietf-http-wg@w3.org; Wed, 05 Oct 2016 19:54:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+6kPLMVdHggptQyw3VSC0XxnPKdBCIbOUwiVVyGTW40=; b=bXS5DwdrHWWE/Q3+QwqoNQrWKJC16iYHnHySNF9nPpEgt2uVhYrtnwKQJJSQos9/tM4CXXzRfRaCmfIQh5HBZqe0xDagrOBuexnz4seC2wYM4t1DGdU6OjLqwqUNCr1hbUF4woAwFedIQRBD2ZSzALRkgBmc8ASr4UKf/z6a9VQ=
Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) 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 19:54:03 +0000
Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0649.024; Wed, 5 Oct 2016 19:54:03 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Martin Thomson <martin.thomson@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Thread-Topic: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Thread-Index: AQHSHljT6HkhJe/JXU23HQjGh2kOnqCYiSNggADCiQCAAEOIAIAAQCyAgAAOywCAAAixAIAAJB4AgAAN1wCAACk5gIAAANsg
Date: Wed, 5 Oct 2016 19:54:03 +0000
Message-ID: <BN6PR03MB2708E1B62BAD6293232956B387C40@BN6PR03MB2708.namprd03.prod.outlook.com>
References: <20161004160321.DFB4C111E5@welho-filter1.welho.com> <BN6PR03MB27082C2CF4DC3F8F82354FDE87C50@BN6PR03MB2708.namprd03.prod.outlook.com> <201610050451.u954pomK003643@shell.siilo.fmi.fi> <CAOdDvNpRN_trGi23BpqUxmaLoLvom9+Yiew0GkNkhgwvqw4Bew@mail.gmail.com> <CABkgnnVKeqnyqhgL=jx1WqtcByqHes25XDJ684J+rNwvQt+znQ@mail.gmail.com> <201610051336.u95DaAW2020152@shell.siilo.fmi.fi> <CABkgnnVaBVE8mUxuGXYe-WeM_OkiNHcA=egnb1-nOxtdujShfw@mail.gmail.com> <201610051616.u95GGWcI031833@shell.siilo.fmi.fi> <BN6PR03MB2708B42C6964AA22AF8FFDC487C40@BN6PR03MB2708.namprd03.prod.outlook.com> <201610051933.u95JXbnC013714@shell.siilo.fmi.fi>
In-Reply-To: <201610051933.u95JXbnC013714@shell.siilo.fmi.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2001:4898:80e8:f::500]
x-ms-office365-filtering-correlation-id: 3bd082bd-af30-45fc-b095-08d3ed595bec
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:mSkl3EtiL6TyF6zyH5inSa0grj9/EHjAgrcIPWYvnOw+vyY7AK2BsGtsge1TVOdCv1rdqqphGuuikSEikkUHy3s8HF60PnQXbKqCy+X23y/j6nDTcRjb6+i02OttiR50W5cTZJoIe6t9HmeVjnacDvSj2w06aNoPp3vwy2t13ObBYedo1xe88XO2Iscnax/RydqroUj2B5NIVG0oe5EJAurcBOryupjjDIVcEaQTNy36ALP3O5ydtQC0tmnaYbwMgHcZvE+hxitUu0CKP9qtlvUjIHtguJa5Q4eNZEhagxXuyLfdJDcvxX4pkChFvwZclhu6Y3yYh47GyryvZLizgQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2707;
x-microsoft-antispam-prvs: <BN6PR03MB27070EECE1EF3BD674135FA887C40@BN6PR03MB2707.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(150554046322364)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707;
x-forefront-prvs: 008663486A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(377454003)(199003)(4326007)(10400500002)(5005710100001)(2906002)(110136003)(92566002)(10090500001)(7696004)(5660300001)(11100500001)(93886004)(8990500004)(5002640100001)(230783001)(8936002)(7846002)(86362001)(7736002)(2900100001)(81166006)(86612001)(8676002)(81156014)(9686002)(305945005)(68736007)(74316002)(2950100002)(6916009)(10290500002)(33656002)(19580405001)(19580395003)(77096005)(76576001)(15975445007)(122556002)(97736004)(189998001)(3660700001)(106116001)(101416001)(105586002)(3280700002)(6116002)(102836003)(106356001)(87936001)(99286002)(76176999)(586003)(50986999)(54356999)(3826002)(376185003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 19:54:03.7841 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707
Received-SPF: pass client-ip=104.47.34.105; envelope-from=Michael.Bishop@microsoft.com; helo=NAM01-BY2-obe.outbound.protection.outlook.com
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: maggie.w3.org 1brsGt-0005nt-FB b919043eae9019163ff55d89a1a6d3cf
X-Original-To: ietf-http-wg@w3.org
Subject: RE: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt
Archived-At: <http://www.w3.org/mid/BN6PR03MB2708E1B62BAD6293232956B387C40@BN6PR03MB2708.namprd03.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32492
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>

Well, origin includes scheme, so yes -- if it's terminating HTTP and switching on origin, that means it's looking at the scheme.  That doesn't imply it needs to pass through the MIXED_SCHEME or whatever from the back-end, since it will have its own connections to the back-end servers.  Those will control whether the reverse proxy can mix scheme in its connections to the back end servers, but that doesn't affect whether it supports a mixed scheme on its front.  It will have a potentially-complex set of rules on what requests get served from which back-end server and how.

If it's just a load balancer, possibly terminating TLS, then the HTTP connection terminates at a single back-end, which either supports a mix or not.  In this case, the load balancer would be switching on hostname, not origin, if that.

As to the last, my point is that this document is describing how an alternative can indicate that it doesn't have the problems called out in RFC 7838 section 9.5.  But that section already says, in effect, "don't point to an alternative that has this problem."  So I'm not clear what new additional information is being conveyed here, other than that the origin's Alt-Svc header wasn't sent in error.

(ELI5 => "Explain Like I'm 5" => give me a very simple explanation)

-----Original Message-----
From: hurtta@siilo.fmi.fi [mailto:hurtta@siilo.fmi.fi] On Behalf Of Kari Hurtta
Sent: Wednesday, October 5, 2016 12:34 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>rg>; Martin Thomson <martin.thomson@gmail.com>om>; Patrick McManus <mcmanus@ducksong.com>om>; HTTP working group mailing list <ietf-http-wg@w3.org>
Subject: Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

Mike Bishop <Michael.Bishop@microsoft.com>om>: (Wed Oct  5 20:28:20 2016)
> 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 alternate.example.com:443 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.

This is seemingly about that part of my comment:

  >> connection apply probably for several origins. TLS connection
  >> may be terminated by reverse proxy. And different origins
  >> are served by different processes or servers behind of
  >> reverse proxy.
  >>
  >> I guess that SETTINGS_MIXED_SCHEME_PERMITTED is too wide.

Yes, that depends what you want validate.

I was envisioning that selection of back end server spool on reverse proxy / load balancer is function of origin.

( Yes, this imply that TLS is terminated here )

Effectively you are saying that selection of back end server spool on reverse proxy / load balancer must be function of origin AND scheme. Or that that reverse proxy / load balancer must check scheme.

Yes, it is possible to require that SETTINGS_MIXED_SCHEME_PERMITTED is not sent if reverse proxy / load balancer does not check itself scheme.

If reverse proxy / load balancer checks scheme and found that http: is used, it need get SETTINGS_MIXED_SCHEME_PERMITTED from backend server (if HTTP/2 is used) or use white list for secure backend servers / pools or refuse request.

White list tells that which backend servers / pools check scheme, in that case http:  -request can be sent ot here.

If selection of back end server / server pool is function of origin AND scheme, then request can be sent to that server / pool which is for http: -scheme.


> Again, that's RFC 7838 ("mitigate ... by refraining from advertising alternative services for insecure schemes.").

That is

|   refraining from advertising alternative services for insecure schemes
|   (for example, HTTP).


And whole draft is about advertising alternative services for
http -scheme.

I'm really confused.

> Can someone ELI5?

I do not found that from dictionary.

/ Kari Hurtta