Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

Andrei Popov <> Wed, 06 June 2018 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6701E129385 for <>; Wed, 6 Jun 2018 11:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.021
X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lPliQKtqwNbY for <>; Wed, 6 Jun 2018 11:52:01 -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 A7D3F129619 for <>; Wed, 6 Jun 2018 11:51:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gfrQZFTjo0IpRbwdb4jVCBG+dq47BJd3mxqp9KBmeyA=; b=JFUykzrXgCX4zhgfE86tTWUNOZV3shIPohF7fyRK2Z5h8rLo9n8C73DZNvitE75cR7oe+mVtsSI65JXlUUAmfRthlnCqwEJh64nuk0K0Oyk+xgkX7ZIMjLoCmnirIMzEOSGXhW+zqGjOuDWw9Wlq1UMvvxwRNBhvZ0M1qMQCRrU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.7; Wed, 6 Jun 2018 18:51:56 +0000
Received: from ([fe80::7cac:8247:7a46:1bfd]) by ([fe80::7cac:8247:7a46:1bfd%16]) with mapi id 15.20.0863.004; Wed, 6 Jun 2018 18:51:56 +0000
From: Andrei Popov <>
To: Brian Campbell <>, Leif Johansson <>
CC: IETF Tokbind WG <>
Thread-Topic: [Unbearable] tokbind - New Meeting Session Request for IETF 102
Date: Wed, 06 Jun 2018 18:51:56 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e8:1:28bc:a023:971b:e42c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0284; 7:u2Umk6kB557HA7FIcTFe77l0OoU3lcXajBFUMTo5esKvYi6WyALbZ+Kj4zP2YTxkzFtETMBb9xRXx1or+2kwPgOMc4DWykgYhe4Ya38CqEsXyc7zIYoqPhbhzvWiHaZDO8SMrzIY2y9cydbEvQspsOOJYFS3Fd1QpHKBB+ayZ9Saf8K4pMJq8XvyvRmAUohbOYo8i6ob9e4kLqe7fK8/8/h3WXsjAEgDaQznGdHSuKdaIvBOglXSrUj5U/zh4V8I
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR21MB0284;
x-ms-traffictypediagnostic: DM5PR21MB0284:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(189930954265078)(100405760836317)(219752817060721)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR21MB0284; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0284;
x-forefront-prvs: 06952FC175
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39380400002)(396003)(39860400002)(189003)(199004)(6116002)(6436002)(4326008)(229853002)(19609705001)(1600100001)(966005)(2906002)(76176011)(55016002)(2900100001)(10290500003)(5250100002)(99286004)(6246003)(14454004)(478600001)(7696005)(8936002)(81156014)(81166006)(5660300001)(8676002)(33656002)(68736007)(446003)(11346002)(5890100001)(486006)(606006)(72206003)(476003)(22452003)(105586002)(74316002)(93886005)(7736002)(316002)(110136005)(10090500001)(9686003)(54896002)(186003)(236005)(3280700002)(86612001)(53546011)(6506007)(97736004)(59450400001)(86362001)(102836004)(53936002)(790700001)(25786009)(46003)(3660700001)(8990500004)(106356001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0284;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: XysHpkGmtqaZfbYzlLyd9bOAD/FlD+VxLz29sGmESB/mBJOy270JePIk7QeWpPOMraBcuCROFUJ/8fIuBVJqbpnGoZY6LLaG/DQ+DF0Esp12YsDYxWFhFTISgHlG3U0T6lUHUGkfIPSPfNvsU9xchUGAXYUOzMNehEx/udFljtFElosySYFaP9scPtrh9OiS
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR21MB050756924C75D2A4CB31826C8C650DM5PR21MB0507namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: e8b40a0a-b268-44b5-2972-08d5cbde938f
X-MS-Exchange-CrossTenant-Network-Message-Id: e8b40a0a-b268-44b5-2972-08d5cbde938f
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 18:51:56.1164 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0284
Archived-At: <>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102
X-Mailman-Version: 2.1.26
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: Wed, 06 Jun 2018 18:52:06 -0000

The document is well-written and clear, overall. I have a few editorial comments and some design comments:

  “Token Binding over HTTP [I-D.ietf-tokbind-https] provides a mechanism
   that enables HTTP servers to cryptographically bind cookies and other
   security tokens to a key held by the browser or other HTTP client,
   possession of which is proven on the TLS [RFC5246] connections over
   which the tokens are used.”

Editorial suggestion: “…to a key generated by the client.” Whether the browser, HTTP client, or underlying platform hold the TB key is implementation-specific and probably unnecessary detail here. Proof of possession is discussed in the next sentence.

  “The usage of the headers, both the reverse proxy adding _it_ and the
   application server using _them_ to bind cookies or other tokens, are to
   be configuration options of the respective systems as they will not
   always be applicable.”

Editorial: this sentence confuses me, esp. around “it” and “them”; perhaps it’s possible to simplify.

Section 2.2: Having three separate headers: Sec-Provided, Sec-Referred and Sec-Other catch-all would not be my design choice. I’d suggest either one header with a list of all TB IDs, or a separate header for each TB ID. Of course, if WG consensus exists on the current design, then that’s what it is.

   “Both "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-Binding-
   ID" are single HTTP header field-valued…”

Somewhat related to the previous comment: this seems to be saying that there cannot be more than one referred TB ID, which is fine now, but not necessarily future proof.
TTRP seems to not be versioned; if, say, TB 2.0 uses multiple referred bindings per request, will we need TTRP 2.0 with all new headers?

It seems that TTRP needs to be either TB version-specific, i.e. explicitly say “this is for TB 1.0 only, and future TB versions will require new TTRP specs”, or be designed as a pipeline, passing whatever bindings the proxy was able to verify, possibly along with the negotiated TB protocol version.

Security and IANA considerations look good to me.



From: Unbearable <> On Behalf Of Brian Campbell
Sent: Friday, June 1, 2018 9:07 AM
To: Leif Johansson <>
Cc: IETF Tokbind WG <>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

It's pretty short!<>

On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <<>> wrote:

On 2018-06-01 00:49, Brian Campbell wrote:
> I'd like to request some agenda time to cover the TTRP draft, which will
> likely consist of an overview and status update (with some gratuitous
> photos of recent IETF meeting locations) and a plea to move towards
> WGLC. Thanks!

In order to facilitate that... could we get some folks to review
the TTRP draft before 102?

Maybe... please... ??

        Cheers Leif

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.