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

Andrei Popov <> Thu, 10 May 2018 05:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0995612EA5A; Wed, 9 May 2018 22:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dUl52eJbQrGW; Wed, 9 May 2018 22:21:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2607012EA58; Wed, 9 May 2018 22:21:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WUF+ethIpoVOT35pIe6AVvMHpBvyIbUZlA7ex+oanu4=; b=FYK8x3R1gF1KWEsZBS6025T98Txv0gsZxKq6sVrQ2pdZUZFeJyklf5Sb69897lRb7gVLClvWht//P6JQhzTO0bPIUW0yh1HAx+5TYkRmDuV5z8Spm5oE7F87A2et3GLAFDU3osATCzuIVb5WzYOFGaJtP1iPjIxqiC1YkzMBNKA=
Received: from ( by ( 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 ([fe80::49e8:420f:baa2:a62f]) by ([fe80::49e8:420f:baa2:a62f%6]) with mapi id 15.20.0776.004; Thu, 10 May 2018 05:21:17 +0000
From: Andrei Popov <>
To: Ben Campbell <>, Eric Rescorla <>
CC: The IESG <>, John Bradley <>, "" <>, IETF Tokbind WG <>, "" <>
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: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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_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: []
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 );
x-microsoft-antispam-prvs: <>
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;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( 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-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: <>
Subject: Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)
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.\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 
Sent: Wednesday, May 9, 2018 9:40 PM
To: Eric Rescorla <>
Cc: The IESG <>; John Bradley <>;; IETF Tokbind WG <>;
Subject: Re: Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)

> On May 9, 2018, at 4:05 PM, Eric Rescorla <> wrote:
> On Wed, May 9, 2018 at 1:05 PM, Ben Campbell <> 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 
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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?