Re: [Unbearable] Benjamin Kaduk's Yes on draft-ietf-tokbind-negotiation-13: (with COMMENT)

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 10 May 2018 18:54 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 2669312EB87; Thu, 10 May 2018 11:54:47 -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 AO8OtTiGV7Qw; Thu, 10 May 2018 11:54:45 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0136.outbound.protection.outlook.com [104.47.33.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB0A12EB82; Thu, 10 May 2018 11:54:44 -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=MZLOleJL1RmltheHIZjf5yApZY/N/6O9MrBryZvxk74=; b=l7WI8MEhVLWG6OYOxBLOQ/ur8H2d2m+HfEOr6Rp6nHQFb/9r+/iW9dFznzFJv/m3m8rcYmdmcJc5mlPcTuAzkSZVO9nurd2ZUI2AoaQp3/TbpCZ6LzweYRe2dUzTijVizR9hJ73IefrMYy9qr6IoJG+AxWxcQise6Tqc1iREf5U=
Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0857.namprd21.prod.outlook.com (10.173.172.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.2; Thu, 10 May 2018 18:54:43 +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 18:54:43 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-tokbind-negotiation@ietf.org" <draft-ietf-tokbind-negotiation@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>, "ve7jtb@ve7jtb.com" <ve7jtb@ve7jtb.com>, "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: Benjamin Kaduk's Yes on draft-ietf-tokbind-negotiation-13: (with COMMENT)
Thread-Index: AQHT6FzDVHf22XrxuEm0q7plWdClnqQpT9tQ
Date: Thu, 10 May 2018 18:54:42 +0000
Message-ID: <DM5PR21MB0507CCE9A4EB9B03A25F70478C980@DM5PR21MB0507.namprd21.prod.outlook.com>
References: <152595631970.10267.10188172038443610412.idtracker@ietfa.amsl.com>
In-Reply-To: <152595631970.10267.10188172038443610412.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:c::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0857; 7:uj37zGydHlM1DaQDSM6hI29UaIConEgFJYOVpt+OktPKgU1OX33R1rnv+QC4SikkpIede1OF11GKnx19zDdH6Vtdhwmszw89GQ4Z/H8cMcsSa/YgA9w/gaC41xzzwMwNqSjtLbVxm1ULanfCsE7toBJPNgc1nAsfR788Tg4hAbxQ7Dk45JXMst/ZojARlpt741YtPsBljAmX/Q3nVsQgcRjmeiYR7zWUA775/SN+LhJEj7ETDI89q2xIZBfvCn+0; 20:y/e2TkyKICpiooILVNepOWs4Udin7fZuZHJdyxH6NA14Q/CHSXPbuU03aWMYofRgdn6hiCVcpdVICrSi00kEBGyQ95Tw5U3HxeJ1tAes37SrdSjf4UGHdtCg9Omr08VP2jhkj3QQOaQZtTxOvA15/9M43/0GNVEQ37ptovaDqNo=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7193020); SRVR:DM5PR21MB0857;
x-ms-traffictypediagnostic: DM5PR21MB0857:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-microsoft-antispam-prvs: <DM5PR21MB08579F1A2E5F2ECD5B83F6898C980@DM5PR21MB0857.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721)(240460790083961);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(2018427008)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR21MB0857; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0857;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(396003)(39380400002)(366004)(189003)(54094003)(199004)(13464003)(186003)(11346002)(105586002)(14454004)(33656002)(3280700002)(476003)(106356001)(53546011)(97736004)(74316002)(46003)(4326008)(446003)(81156014)(2906002)(2900100001)(7696005)(68736007)(81166006)(8936002)(76176011)(5660300001)(486006)(3660700001)(6506007)(8676002)(102836004)(5250100002)(10090500001)(86612001)(316002)(478600001)(54906003)(99286004)(9686003)(72206003)(110136005)(6306002)(2171002)(305945005)(86362001)(575784001)(6246003)(6116002)(8990500004)(22452003)(25786009)(53936002)(10290500003)(966005)(229853002)(6436002)(7736002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0857; H:DM5PR21MB0507.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Dbxhj/Ky1xlrXBlFCzJbgkv5bmUZZnfTFg6GfBF2xDMx/lH7C+KogmDyzccEmQN/1XxnCIKH5D4xOgMZj+3+6QunCI6aQZB8YbnQXOJBzEwDkDdB8WtHLgtMj5Yxcr4nDUZbK4UtJu0tWS1OVklHsH7YWld63k3SSO+6cRpobqDwD+fq8nExXPGvKIifROa4
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: a15a1948-2611-4502-400a-08d5b6a77ddf
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a15a1948-2611-4502-400a-08d5b6a77ddf
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 18:54:42.9028 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0857
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/PUiZaP4zQkqSJhpLji_Eb0fXmgs>
Subject: Re: [Unbearable] Benjamin Kaduk's Yes on draft-ietf-tokbind-negotiation-13: (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 18:54:47 -0000

Thanks Benjamin, will address in the next revision of the draft.

-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu> 
Sent: Thursday, May 10, 2018 5:45 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tokbind-negotiation@ietf.org; John Bradley <ve7jtb@ve7jtb.com>om>; tokbind-chairs@ietf.org; ve7jtb@ve7jtb.com; unbearable@ietf.org
Subject: Benjamin Kaduk's Yes on draft-ietf-tokbind-negotiation-13: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tokbind-negotiation-13: 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Ca23e5531d38948efbae708d5b673e4a5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615531239212874&sdata=L66zSzyyL7FmZM7r6IqxxmUf2nTukJlQYpCwglIarVU%3D&reserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-negotiation%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Ca23e5531d38948efbae708d5b673e4a5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615531239212874&sdata=h%2Bz51Cy2X3riIOrtIOPjQqjcAEJ0kamn%2Bgpkzu%2BghrQ%3D&reserved=0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Adam and Warren's comments.

The point already made about version negotiation has a corollary that if the client sends a dense list of versions, then the server will know decisively that a specific version has (or has not) been negotiated, and can rely on that at the application layer.  When the client can receive an unsupported version back from the server, the client will not use token binding and the server has to infer from the client's application-layer traffic whether token binding is expected to be in use.  (Whether or not this is a desired or useful property to have is not necessarily clear.)


Section 4

   the client advertises, then the server MUST NOT include
   "token_binding" extension in the server hello.

Nit: """the "token_binding" extension"""


Section 6.1

   The Token Binding protocol version and key parameters are negotiated
   via "token_binding" extension within the TLS handshake. [...]

Nit: """the "token_binding" extension".  (Also at the end of this
paragraph.)

   [...] TLS prevents
   active attackers from modifying the messages of the TLS handshake,
   therefore it is not possible for the attacker to remove or modify the
   "token_binding" extension.

I wonder if we want to explicitly say *successful* TLS handshakes, but given the context in the main protocol document it's probably not necessary.