IETF Logo Mail Archive

Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?

Andrei Popov <Andrei.Popov@microsoft.com> Thu, 02 March 2017 00:55 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 7ECED129459 for <unbearable@ietfa.amsl.com>; Wed, 1 Mar 2017 16:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-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 NWIy-lYaYO-B for <unbearable@ietfa.amsl.com>; Wed, 1 Mar 2017 16:55:04 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0130.outbound.protection.outlook.com [104.47.37.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D90129455 for <unbearable@ietf.org>; Wed, 1 Mar 2017 16:55:02 -0800 (PST)
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=kVJeTH1sA1mvtlsHHoVaQiea6zObzo6Z8SmdRzN1Spk=; b=lGtMDQtPScDbrBJaSNLJidfSNRUn2kne+1R5DuScmQHw3DwDq6s+Y7sLS/6GvkvNdTAwCXZArrlNVjERE35XzWfNJFvFc0aMcP1sGHCvJ09xsIuUL5qg45iRzBrSvH2H0VrhZx4KGsRvFrx+AfRV8OYBKGVeDWM8VpJKRrynh34=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.3; Thu, 2 Mar 2017 00:54:59 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.0961.004; Thu, 2 Mar 2017 00:54:59 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Martin Thomson <martin.thomson@gmail.com>, Nick Harper <nharper@google.com>
Thread-Topic: [Unbearable] 0-RTT Token Binding: When to switch exporters?
Thread-Index: AQHSbdvurWwJUrGAZkyxVvys5avGZKE28kcggCd4oACAH07+gIABRECQgAAemICAAAhjEIAAGSoAgAAPAQCAAAUIUIAAII2AgAACEkCAAYowAIAAA7aAgAAAjZA=
Date: Thu, 02 Mar 2017 00:54:58 +0000
Message-ID: <DM2PR21MB0091DE5B213D2363FAF353CF8C280@DM2PR21MB0091.namprd21.prod.outlook.com>
References: <CACdeXiK2Hs=Kz_5OFryWR+9_t6nDL_p7NKjw=CwRsua_E5S9Mw@mail.gmail.com> <DM2PR0301MB084793F58146F8574BF36EE18C780@DM2PR0301MB0847.namprd03.prod.outlook.com> <CACdeXiJGcsTxrSWmd5BZrfoWTHhFF3+RisQFD628iYNMzZakhQ@mail.gmail.com> <CACdeXiJFe7-jM9qEnNB+Wp3joGxF_X1z+-dPywb9SRZuSNmAzQ@mail.gmail.com> <DM2PR21MB0091E3F087E1AECA3A63A3788C560@DM2PR21MB0091.namprd21.prod.outlook.com> <CACdeXi+YjLaXtoX47LtVK4Ay2y-mCOOraV46gbbbuQPL40ngXg@mail.gmail.com> <DM2PR21MB00910C83983BEE885B0E04288C560@DM2PR21MB0091.namprd21.prod.outlook.com> <CACdeXiLON5OAjfFCNsenCeaGV3a_LDoi17VAk=fSzF0YA5=f7Q@mail.gmail.com> <CACdeXiLNCrPSz0_hZSpQ6tsoHB7ryJ2dCnHjUYwu5vu5fO4XBg@mail.gmail.com> <SN1PR21MB0096D7426A4E230E284F0D058C560@SN1PR21MB0096.namprd21.prod.outlook.com> <CACdeXiKuzNh0fP9b-jEF82m-6mX+i04To96GMa_tFNcuznGn+A@mail.gmail.com> <DM2PR21MB00914BA07BA984E931B88FEB8C290@DM2PR21MB0091.namprd21.prod.outlook.com> <CACdeXiKQjaoAArLBcjRj+kUJUqH+f1bA5yeCCiQ6GMXzWJURBw@mail.gmail.com> <CABkgnnV0+vumfkZAMRZ_8q5pTkwf_CqhZ+deeVWdbF9SFaHoJw@mail.gmail.com>
In-Reply-To: <CABkgnnV0+vumfkZAMRZ_8q5pTkwf_CqhZ+deeVWdbF9SFaHoJw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:8::1d2]
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0091; 7:xrYJPXfbChCBQuRCg1hOKAk7XQyD8K6FfY7bWcVKlMK17w12PRQwXmF0n66QdjhMQxb+D0Eo4ubHWScWAVzB+MgWRZ0dqKIsgpdURvOSVuivq0o/Is87EzDhjDaTxQzc68cHcmiM1R4HyakBE6kuNxE7oA/IwP0SXqrxP0sdDICIn3Gm3spj3sSe+j+q+BXpFj2+c/1LvEVp9ss/11Te9FOChBKFnUhIo1fsE53+Uak93yQ1ujOkMBi/nAIRQZYiI93/P5/Tn4lAsqkly04xdVXbMx/xJdbtjNsGFJrfkihszhgKb8h3UmPUrBfbQYEnWkoGr9sKRjdUWsWcpChcxNZwMO1ByPzaOB2Wk47lr7w=
x-ms-office365-filtering-correlation-id: d6464db1-6684-4562-457a-08d46106c05b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM2PR21MB0091;
x-microsoft-antispam-prvs: <DM2PR21MB00914ACF976FC8701105F7758C280@DM2PR21MB0091.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(211936372134217);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:DM2PR21MB0091; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0091;
x-forefront-prvs: 023495660C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(24454002)(13464003)(377454003)(6506006)(305945005)(8936002)(7736002)(86612001)(86362001)(6246003)(106116001)(3280700002)(10290500002)(8676002)(74316002)(5005710100001)(77096006)(4326008)(53936002)(99286003)(55016002)(81166006)(229853002)(6306002)(6436002)(25786008)(9686003)(8990500004)(2950100002)(33656002)(3660700001)(5660300001)(6116002)(7696004)(102836003)(10090500001)(189998001)(39060400002)(92566002)(2906002)(93886004)(38730400002)(54356999)(50986999)(2900100001)(76176999)(53546006)(97736004)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0091; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 00:54:58.8487 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0091
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/JNODy3q1IeLPO2cBnnF2qmpeb_4>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.17
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, 02 Mar 2017 00:55:06 -0000

This solution introduces a lot of complexity, but does not address the fundamental problem, which is that the client can't prove possession of the TB key in 0-RTT. So, if I have a site that requires strong protection of tokens with TB, I would disable 0-RTT application data, or at least reject requests that arrive in 0-RTT and require bound tokens to be authorized.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, March 1, 2017 4:53 PM
To: Nick Harper <nharper@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?

Would it help to include a clear signal about which keys are intended to be exported and used?

On 2 March 2017 at 11:39, Nick Harper <nharper@google.com> wrote:
> Does the solution I described upthread (where the client switches 
> exporters soon after the handshake completes, but not necessarily 
> immediately after) sound reasonable, or do we still need to discuss 
> whether we should have any support whatsoever for a 
> TokenBindingMessage in 0-RTT application data? If there are no 
> objections to the upthread solution, I'd like to work on fleshing out 
> the details and revising the I-D.
>
> On Tue, Feb 28, 2017 at 5:31 PM, Andrei Popov 
> <Andrei.Popov@microsoft.com> wrote:
>>> For HTTP, that option would mean a client resuming a connection and sending 0-RTT data can only send in 0-RTT data requests that have no cookies (or other potentially bound tokens), which is a very limited use case.
>> Agreed, this is indeed a limited use-case. But so is 0-RTT application data, if one attempts to use it securely.
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable

v2.23.0 | Report a Bug | By Email