RE: Op-sec simplification

Mike Bishop <> Tue, 01 November 2016 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7B8E12947C for <>; Tue, 1 Nov 2016 10:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.498
X-Spam-Status: No, score=-8.498 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, RP_MATCHES_RCVD=-1.497, 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 GWaQnFH9ZbLF for <>; Tue, 1 Nov 2016 10:38:24 -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 7B288129480 for <>; Tue, 1 Nov 2016 10:38:24 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c1cws-0001vy-8M for; Tue, 01 Nov 2016 17:34:10 +0000
Resent-Date: Tue, 01 Nov 2016 17:34:10 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c1cwl-0001up-Ts for; Tue, 01 Nov 2016 17:34:03 +0000
Received: from ([] by with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c1cwf-00029N-8V for; Tue, 01 Nov 2016 17:33: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=lRNmThP4dbJGijX+bDoUGJ8YalpS6oNTszO92gJZsvM=; b=Vx8GqdqzpC6zj89jU82UTDJ0sQK0uAn9KL8DSReAHk/Ic6PZzg7VDomx2An1L/zfLxxnH9t2WgzZFm1JKFUKcv3VuUT2GAHdDv0tkQeWtoaWjxPwsgUZMpsrSxGRTEgeTzgwhP10G+9uVdnaeBP994T/AlQ3ubcc2RbrZCX4XEg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Tue, 1 Nov 2016 17:33:25 +0000
Received: from ([]) by ([]) with mapi id 15.01.0693.009; Tue, 1 Nov 2016 17:33:25 +0000
From: Mike Bishop <>
To: Martin Thomson <>, Kari Hurtta <>
CC: Mark Nottingham <>, HTTP working group mailing list <>
Thread-Topic: Op-sec simplification
Date: Tue, 1 Nov 2016 17:33:25 +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:8::390]
x-ms-office365-filtering-correlation-id: 7ce9de5e-95ad-4432-929a-08d4027d2f50
x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:6fsU31HDrCwp58W1R/Qu/VsZ+StGdpG+DyZyjFmUAzl1xBB2SNPn4oQsi0M4S84AgS6E2OUGpgMbCRswBMyFAa5NpfA3Et8ZB/5G7R3dbTa162ZWZ+GsZFn/3DkEwY6vJrm8HRrAswkRu6Fw+UwZX2yhZmd3H2QbY/o5IM2BbWm6qsYdfMyWCcQP53kRWRsO7uL4invQAqhhVq5B531e3b6YsdTTY6PbQtdlpqFysYZozv2s8pTTS+Kw8g9KDrGHDI1SUwx9UZ48GR+vZ6RpwpNtyAhWlYjjnmqdeixFi1S2xG0D3LHhqNy5HeOYtvk4abpyaSOEWCW24jyGgwuC3no6SQhn7rl3sHEGz9nmDaUxty49DsJR+W2ts0Ftd4GQ
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2708;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(79290750141951);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(6045074)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6072074); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708;
x-forefront-prvs: 01136D2D90
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(189002)(13464003)(199003)(3280700002)(33656002)(11100500001)(3480700004)(3660700001)(2900100001)(15395725005)(8936002)(106116001)(102836003)(6116002)(92566002)(105586002)(106356001)(99286002)(586003)(8990500004)(10290500002)(86612001)(86362001)(10400500002)(5005710100001)(77096005)(15975445007)(10090500001)(189998001)(5002640100001)(97736004)(5001770100001)(19580405001)(2950100002)(19580395003)(7696004)(50986999)(9686002)(68736007)(54356999)(76176999)(101416001)(93886004)(122556002)(5660300001)(76576001)(81166006)(74316002)(81156014)(8676002)(87936001)(2906002)(4326007)(7846002)(7736002)(305945005)(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: 01 Nov 2016 17:33:25.2648 (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.451, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: 1c1cwf-00029N-8V 9827507047f23d29d19e6d3663b2cba2
Subject: RE: Op-sec simplification
Archived-At: <>
X-Mailing-List: <> archive/latest/32791
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I think the case for TBD2 is that the client sent an "ambiguous" request -- that is, connecting over port 443 and not specifying http:// or https://, but just sending e.g. GET /resource.

The problem is, if that server is also an alternate for, that's not an ambiguous request -- it's a clear request for an https:// resource.  The server can't detect that unless the https:// origin isn't supported there, in which case you're likely to get an existing error (probably 400 for our current code, but a good argument could be made for 421 again).  If the https:// origin is supported there, the client will get a response and never know it asked for (and got) the wrong thing.  The server simply can't fix a broken client, and TBD2 doesn't provide a useful mechanism because the server can't distinguish.

That makes it all the more important that clients know whether the server can support scheme-mixing *and then do it.*  Unless we want to require servers to have distinct scheme-always-required ports, I don't think this is a problem solvable server-side.

-----Original Message-----
From: Martin Thomson [] 
Sent: Monday, October 31, 2016 10:54 PM
To: Kari Hurtta <>
Cc: Mark Nottingham <>et>; HTTP working group mailing list <>
Subject: Re: Op-sec simplification

On 1 November 2016 at 16:25, Kari Hurtta <> wrote:
> That may be good idea. (This spec requires scheme and http/1.1 spec 
> does not allow scheme to be used. )

I have tried to capture this information in a PR:

> |   | TBD1  | Scheme Not Allowed            | Section 2.2 |

We can probably avoid doing that on the basis that we have 421.

> |   | TBD2  | Scheme Required               | Section 2.1 |

The case for this seems weak.  You have to have a resource that is only available on the cleartext version of the site, and you have to use opp-sec, and the client has to be very silly.  I would prefer to use 404 here.  That is, assume that the client asked for a secure resource ( which doesn't exist; rather than asking for the unsecured resource ( which might.