Re: [Unbearable] (late, sorry) WGLC question on establishing the binding or not

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 21 December 2016 02:13 UTC

Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395261296EC for <unbearable@ietfa.amsl.com>; Tue, 20 Dec 2016 18:13:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WSccpQBoGImY for <unbearable@ietfa.amsl.com>; Tue, 20 Dec 2016 18:13:47 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0112.outbound.protection.outlook.com [104.47.42.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBD11293FF for <unbearable@ietf.org>; Tue, 20 Dec 2016 18:13:47 -0800 (PST)
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=zxz1b3kXyKkjzJLbVrcXGX4sMUZn2r5tiNabZnxCxlo=; b=D4AV19bZU58qgU2xx88z+xCP2JfPpGwa/E6I0sconFjOO87sDuwnJhuBuNx0mH5HboQUDK3UuhFSDqmLY6iQTsm2ms5zxg0dYJQH9aQ+0EdHyYZbvZ2xNXQvzRcmd4YG5QHUYQaPKUYyxLJbKte5JniMba2/iH0nzuOq4xltJzw=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 02:13:43 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 02:13:43 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Nick Harper <nharper@google.com>
Thread-Topic: [Unbearable] (late, sorry) WGLC question on establishing the binding or not
Thread-Index: AQHSWvrivRNalV6Ld0i/cnyaQrT2PaERQomAgAABJTCAACXGgIAAJbGggAAS14CAAACIAIAABXOAgAAARkA=
Date: Wed, 21 Dec 2016 02:13:42 +0000
Message-ID: <CY1PR0301MB084255A571DA0559181347648C930@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <CA+k3eCTDfFzVZ-oDVd5JohfoCMAprq_4q5gUs5QjfRQHb2Q+FA@mail.gmail.com> <CY1PR0301MB08427626BD31DB029C1754D98C900@CY1PR0301MB0842.namprd03.prod.outlook.com> <CA+k3eCQjJUWjNSJ_WKz6bB5yhx8qV+fEZHz_KRpj7-ofs-MBsQ@mail.gmail.com> <CACdeXiJVtUhZbv8vY2Zx9dG9Ze7Kgb-S_QQ+7CkAL6dvH980Rw@mail.gmail.com> <CY1PR0301MB084208DBC92146CE08CCB4668C900@CY1PR0301MB0842.namprd03.prod.outlook.com> <CA+k3eCTYgmFmEPgYEdobAuXgQac2ySOywWkEN-d1ixAy9H=O_w@mail.gmail.com> <CY1PR0301MB0842D8B16A4EBCC099E6DC8E8C930@CY1PR0301MB0842.namprd03.prod.outlook.com> <CACdeXiL73MkZsVUrFogrko+=mYLsC-A4xPsZmUer_eRjYpm+Fw@mail.gmail.com> <CY1PR0301MB0842F91C321A8F402529A26B8C930@CY1PR0301MB0842.namprd03.prod.outlook.com> <CACdeXi+uR96HEat5OSE-L=X=RoO1z9pH0t6X0whciTvhgw3GLg@mail.gmail.com>
In-Reply-To: <CACdeXi+uR96HEat5OSE-L=X=RoO1z9pH0t6X0whciTvhgw3GLg@mail.gmail.com>
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=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:7::1d2]
x-ms-office365-filtering-correlation-id: f7524689-5518-44f7-9972-08d42946fcd7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0301MB0841;
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 7:sBlmmpqW5M8PJIIl6CudUKTXDcUwdXiFMMepzTgw+2J9RzEcoWjXuah8SRrWKqH8yoNEteBKo1TWzdP6FWVXsncKgmlzC1PzFxlXMytPF8DMkkxEFZOv3m/JVpRkqcRFvCoteuhl1CRLSh+1msWzdSVN67TRHkgXAt8ic9p8X7KvUNUnF3h25984OtrEGWYVIlVpEdtqDVMo2CYBWGOlrSE+igt6AS6FjPR3NXFpwi6okR/xIJ/YLCBEEYoTbfG4GbRFkn75AieuxNoMrjlhtEuSC6oj6fNwRz9lTttFJCpB6BH44+7U8pcnct+JzimJvfnpQysW3ZYs3Ic3cB0Eiu1oXV8R/MenUlqNWRCsmp0c2MdEYdPbotKQaDkQkXPV4JbiVi4aYL0QSz5o4Lx+F4Lcj2/LnvREz6jVLrmn+TS0udq4CKHGpi+f0nKfEb6rDZj5lCUkkyhOj/U4KHUhgQ9B9KJkmTsbOtwbywK4xxU=
x-microsoft-antispam-prvs: <CY1PR0301MB0841FF8C3B56F6032A9BA12B8C930@CY1PR0301MB0841.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841;
x-forefront-prvs: 01630974C0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39860400002)(39850400002)(39410400002)(189002)(377454003)(51444003)(199003)(54356999)(76176999)(2950100002)(6916009)(6116002)(102836003)(790700001)(10090500001)(8676002)(81156014)(81166006)(189998001)(4326007)(50986999)(2906002)(5660300001)(76576001)(19609705001)(122556002)(8936002)(229853002)(101416001)(8990500004)(110136003)(68736007)(38730400001)(10290500002)(7696004)(5005710100001)(93886004)(86362001)(3280700002)(74316002)(86612001)(3660700001)(7736002)(77096006)(6436002)(106116001)(105586002)(106356001)(6506006)(99286002)(25786008)(9686002)(97736004)(2900100001)(92566002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.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: multipart/alternative; boundary="_000_CY1PR0301MB084255A571DA0559181347648C930CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2016 02:13:43.0008 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/fcvUm0pdcaTh7q0XdpNXBeyIWGQ>
Cc: IETF Tokbind WG <unbearable@ietf.org>, Brian Campbell <bcampbell@pingidentity.com>
Subject: Re: [Unbearable] (late, sorry) WGLC question on establishing the binding or not
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2016 02:13:49 -0000

What if instead we say in HTTPSTB that if the server is configured to require TB, then this server MUST reject HTTP requests lacking TB headers?

This avoids:

1.       The issue of the first vs. subsequent requests;

2.       The corner-casing of servers negotiating the client-offered TB version vs. a lower TB version;

3.       The squishiness of SHOULD.

From: Nick Harper [mailto:nharper@google.com]
Sent: Tuesday, December 20, 2016 6:07 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>; IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] (late, sorry) WGLC question on establishing the binding or not

That could be changed to "A server SHOULD reject a client's first application protocol message...", and I think that fixes that problem. However, that doesn't cover the case of other application protocol messages lacking a TB message when the application profile (e.g. HTTPSTB) expects there to be one. The intention is that if the client disobeys the MUSTs in that first paragraph, then the server is fine to reject the message. (I was hoping that "an application protocol message" instead of "any application protocol message" would be vague enough to get around the first message vs every message restriction, but that isn't the case.)