Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 10 May 2018 05:21 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 0995612EA5A; Wed, 9 May 2018 22:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 dUl52eJbQrGW; Wed, 9 May 2018 22:21:19 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0111.outbound.protection.outlook.com [104.47.36.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2607012EA58; Wed, 9 May 2018 22:21:19 -0700 (PDT)
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=WUF+ethIpoVOT35pIe6AVvMHpBvyIbUZlA7ex+oanu4=; b=FYK8x3R1gF1KWEsZBS6025T98Txv0gsZxKq6sVrQ2pdZUZFeJyklf5Sb69897lRb7gVLClvWht//P6JQhzTO0bPIUW0yh1HAx+5TYkRmDuV5z8Spm5oE7F87A2et3GLAFDU3osATCzuIVb5WzYOFGaJtP1iPjIxqiC1YkzMBNKA=
Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0124.namprd21.prod.outlook.com (10.173.173.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.3; Thu, 10 May 2018 05:21:17 +0000
Received: from DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::49e8:420f:baa2:a62f]) by DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::49e8:420f:baa2:a62f%6]) with mapi id 15.20.0776.004; Thu, 10 May 2018 05:21:17 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Ben Campbell <ben@nostrum.com>, Eric Rescorla <ekr@rtfm.com>
CC: The IESG <iesg@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, "draft-ietf-tokbind-negotiation@ietf.org" <draft-ietf-tokbind-negotiation@ietf.org>, IETF Tokbind WG <unbearable@ietf.org>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>
Thread-Topic: Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)
Thread-Index: AQHT59EiwpQ8z5zuzESbJ1S4FE6uo6Qn4yYAgAB/JoCAAAoBYA==
Date: Thu, 10 May 2018 05:21:16 +0000
Message-ID: <DM5PR21MB0507C0DA6D4B8624B935FFEF8C980@DM5PR21MB0507.namprd21.prod.outlook.com>
References: <152589634849.4060.1233669853296271255.idtracker@ietfa.amsl.com> <CABcZeBM+u7xCCTrhnua8+SRZM6ruEBMgiew42FdiiN-=8tZryQ@mail.gmail.com> <B593B23C-435E-4563-ACAC-8FDC4FCBA431@nostrum.com>
In-Reply-To: <B593B23C-435E-4563-ACAC-8FDC4FCBA431@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=andreipo@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-05-10T05:21:15.3542195Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [50.47.136.80]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0124; 7:n++iEO0FOh027W4F8Aq2nutZf4z9ocvJreGIB5JKcQOnoSV08WD7Xu1qtg3E7ws+XUIo2tHuOiKaNg2zGvsQR9+UmQOYybPt7Q0JTiEcpCoVdHXiF3vRlAl0YtDAzP+RFWkPI5XA6mMhK2XhDA424fjMsrkHVDhREAXsCEpjjkqAkn9jHixcMW8W3JKIz4aVxTz1JldMbkblE6VVvDZ99vHn62dNzvbbS7+DvixkYx+mQPdQTokJdnRe1OekQniS; 20:w0Qud0Plfk6VcFZSwl2Vy1OQwFbhUSbk+JyF+AR7qe9d5GUzcOEupsNu1R5W/YkyVYdCaurccbiDUWDusciUYUPVYyDvtFJ95TfzV65a10bRZoXpinahHJBNcalOY54j8fcI6BdosQOLegmoUFxs0FH802Zy+WfvYr7X6ovKP/w=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:DM5PR21MB0124;
x-ms-traffictypediagnostic: DM5PR21MB0124:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-microsoft-antispam-prvs: <DM5PR21MB0124C659B671DB3F165E7CDD8C980@DM5PR21MB0124.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(120809045254105);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(2018427008)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR21MB0124; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0124;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(366004)(376002)(346002)(199004)(189003)(13464003)(54906003)(22452003)(86612001)(110136005)(68736007)(6246003)(97736004)(86362001)(8936002)(102836004)(74316002)(316002)(7696005)(8676002)(53546011)(105586002)(99286004)(33656002)(476003)(81166006)(81156014)(305945005)(53936002)(5660300001)(76176011)(55016002)(106356001)(186003)(59450400001)(6506007)(966005)(3280700002)(6436002)(10090500001)(26005)(8990500004)(10290500003)(25786009)(2900100001)(14454004)(446003)(7736002)(4326008)(3660700001)(6116002)(72206003)(5250100002)(229853002)(66066001)(9686003)(11346002)(2906002)(3846002)(478600001)(6306002)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0124; H:DM5PR21MB0507.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: QTeR+QaaQPjaavX3/93a6Zn9x3FIq40YhRR1wFo+JAjxz1A63fZm6OWry77v7qAsfb2Ihq0CO8aoiKo3DpvfQl9m51j2YCBXrHL5S2KrRgOPFfSOGVpFoMDiSQyERnijvRHYfcVpfygM7XCc0AjyyTLD6A1TOZ04rtuaD+ir4cm7CZxfNoWWRFS2w8mrVZdv
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 8e3a36d8-55a3-4a25-f20d-08d5b635db38
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e3a36d8-55a3-4a25-f20d-08d5b635db38
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 05:21:16.9266 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0124
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/xSzdaK3_TB6O99cMqQQbMGJIHOM>
Subject: Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 10 May 2018 05:21:22 -0000

> Just to make sure I understand: If the client selects version N (ignoring the (major, minor) format for a minute) , the server might respond with N-1. If the client doesn’t like N-1, it aborts and optionally tries again with the highest version it supports that is lower than N-1? Or should it just give up on TB?

Nothing in the document prevents the client from re-trying in this fashion, but the prototype clients I've seen (Web browsers) proceed without TB in this situation.

Here's what the spec says about handling TB negotiation failures:
   "Client and server applications can choose to handle failure to
   negotiate Token Binding in a variety of ways, e.g.: continue using
   the connection as usual, shorten the lifetime of tokens issued during
   this connection, require stronger authentication, terminate the
   connection, etc."

-----Original Message-----
From: Ben Campbell <ben@nostrum.com> 
Sent: Wednesday, May 9, 2018 9:40 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>rg>; John Bradley <ve7jtb@ve7jtb.com>om>; draft-ietf-tokbind-negotiation@ietf.org; IETF Tokbind WG <unbearable@ietf.org>rg>; tokbind-chairs@ietf.org
Subject: Re: Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)



> On May 9, 2018, at 4:05 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Wed, May 9, 2018 at 1:05 PM, Ben Campbell <ben@nostrum.com> wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-tokbind-negotiation-12: Yes
> 
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this document. I am balloting "yes", but have a few comments:
> 
> - I support Alexey's DISCUSS. Additionally, do I understand the 
> version negotiation to require the client to support all previous 
> version from the one it initially advertises? If so, how would you 
> deprecate a version at some time in the future?
> 
> You can't do it in the CH. The assumption is that the server will pick 
> the highest common version in the SH and if you don't support that, you abort.

Just to make sure I understand: If the client selects version N (ignoring the (major, minor) format for a minute) , the server might respond with N-1. If the client doesn’t like N-1, it aborts and optionally tries again with the highest version it supports that is lower than N-1? Or should it just give up on TB?

Thanks,

Ben.