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

Andrei Popov <> Thu, 10 May 2018 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60E9F12EB9B; Thu, 10 May 2018 12:01:21 -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 FxsJ1eWo4LVq; Thu, 10 May 2018 12:01: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 EB27912ECCA; Thu, 10 May 2018 12:01:00 -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=DCDoZHqRNfQzvF7nG5zWaWyeH4M60d7ksnEXabxWYDI=; b=mEU+ZNja84zqAz+Ku6NnROdXpC3+fD5urV51rQ8Bnah4sCCP46loANNuzpRf9h6RGrDdNnIhVc6bt9kfDlwRJRssKNqIuZifNMVrJVjNKRW4QELgZVLp65sImJgkYkMOJkZIkFsOSDz0Qa59YzRtAcwFKs7gp4T2qUC3rzhGUow=
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 19:00:59 +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 19:00:59 +0000
From: Andrei Popov <>
To: Benjamin Kaduk <>, The IESG <>
CC: "" <>, John Bradley <>, "" <>, "" <>, "" <>
Thread-Topic: Benjamin Kaduk's Yes on draft-ietf-tokbind-protocol-18: (with COMMENT)
Thread-Index: AQHT6FlMlK9sjnJuFkKz1yIilpgc2qQpUV6g
Date: Thu, 10 May 2018 19:00:59 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e8:c::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0777; 7:oVV8l4PpJtw+6WM9rV81Ei9prfII2POD+9Hvty/ULfR167XbkpHxUyf9JuW/l8B7eO86bztEWjNm//cwKf3dGlJa6jZ87B8IE71Z+R3LfhLXAvfew9PGSpzpGslEEGFEYzkYEaFZAxdJEO0MzpFUaFjNTnz9ZpSvaUdeOXUlE1hnB2zDVswmkYqrbR6qh7utfXCtyj8v7td7pP97b63dM1UuWIhjMSEvGOI5q7VNpsub7bTJZg14pcx/QC9eBDOw; 20:PR0vlXjg8B7o5ja+/jIxuIJX14usAOWFaf+q5F06q0BqSwlKMY+ja+xTg7t3uiZ6FNDqfgWPWxCDQ4wN/Ox+5N68gY4753TDB89KjvVOBDSSfEsbfcZwxZWkiRXywLlzPJT9ZMb8aNbOCEIjAecfS4/l0kQd72y2A9XxK3TdtNY=
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:DM5PR21MB0777;
x-ms-traffictypediagnostic: DM5PR21MB0777:
x-microsoft-antispam-prvs: <>
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)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR21MB0777; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0777;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(376002)(346002)(39860400002)(396003)(189003)(199004)(13464003)(446003)(478600001)(966005)(316002)(9686003)(476003)(14454004)(6116002)(25786009)(53936002)(6306002)(2171002)(54906003)(97736004)(10090500001)(486006)(72206003)(186003)(55016002)(33656002)(10290500003)(8936002)(11346002)(6436002)(2900100001)(229853002)(46003)(5250100002)(53546011)(81156014)(81166006)(8676002)(2906002)(110136005)(7736002)(86612001)(68736007)(86362001)(5660300001)(59450400001)(99286004)(76176011)(305945005)(102836004)(3660700001)(6246003)(22452003)(74316002)(105586002)(4326008)(6506007)(7696005)(3280700002)(6346003)(8990500004)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0777;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-message-info: tADvExuLyK+tvgQzUyCMvwfN/UU2srJDOSI08e8tE9YahWw+FjUtFleYLqSX8vg+CWn/0c1uBVstXLDQyn6nLscF/2TEICYmuGGYwnfsJN9SCfB4df0g4sYONsCTvnnh/ayUpaA7On02A2sYCvMzwF41RHTpR+VNA3EquXcJyFzfcOQFgQXm+RUsSYa/ZGYb
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: 21b64284-62ff-4ad2-6079-08d5b6a85e1d
X-MS-Exchange-CrossTenant-Network-Message-Id: 21b64284-62ff-4ad2-6079-08d5b6a85e1d
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 19:00:59.1406 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0777
Archived-At: <>
Subject: Re: [Unbearable] Benjamin Kaduk's Yes on draft-ietf-tokbind-protocol-18: (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 19:01:21 -0000

Several good catches here; will address in the next revision.



-----Original Message-----
From: Benjamin Kaduk <> 
Sent: Thursday, May 10, 2018 5:21 AM
To: The IESG <>
Cc:; John Bradley <>om>;;;
Subject: Benjamin Kaduk's Yes on draft-ietf-tokbind-protocol-18: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tokbind-protocol-18: 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:


Section 2

   When a server supporting the Token Binding protocol receives a bound
   token, the server compares the Token Binding ID in the token with the
   Token Binding ID established with the client.  If the bound token
   came from a TLS connection without a Token Binding, or if the Token
   Binding IDs do not match, the token is rejected.

"came from" is perhaps a bit ambiguous; I'd suggest "is received on"

Section 3.3

The need for synchronization between application+token-binding and the TLS stack (around renegotiation) is real, but is also potentially really hard.  Can we get some guidance on how to not screw it up?

Section 3.4

   An implementation MUST ignore any unknown Token Binding types.

This is the section on extensions; do we mean to say that unknown extension types are to be ignored?  (If we do, it would seem to duplicate a line in Section 4.2.)

Section 4.1

   The client MUST include at least one TokenBinding structure in the
   Token Binding message.  The key parameters used in the
   provided_token_binding MUST match those negotiated with the server
   (e.g., via [I-D.ietf-tokbind-negotiation] or a different mechanism).

This seems to imply but not specifically state that the mandatory TokenBinding is of type provided_token_binding.  Changing "the" to "this" in the second line would subtly sneak this in, but it's probably better to also explicitly say "of type provided_token_binding" in the first sentence.

Section 4.2

I would suggest adding a pargaraph break between the sentences in

   If the use of the Token Binding protocol was not negotiated, but the
   client sends the Token Binding message, the server MUST reject any
   contained bindings.  If the Token Binding type is
   "provided_token_binding", the server MUST verify that the signature
   algorithm (including elliptic curve in the case of ECDSA) and key
   length in the Token Binding message match those negotiated with this
   client (e.g., via [I-D.ietf-tokbind-negotiation] or a different

   If a Token Binding is rejected, any associated bound tokens MUST also
   be rejected by the server. [...]

Is "associated" scoped to "presented on the current TLS connection"
or a more global property?  (I understand that the association could be either via direct embedding of ID in token or via an external database mapping.)

Section 6.1

This policy sounds more like "Specification Required" than "Expert Review" (the former still includes expert review).