Re: [Unbearable] Removing explicit public key crypto from Token Binding

Andrei Popov <Andrei.Popov@microsoft.com> Mon, 03 April 2017 17:58 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 C93921294BB for <unbearable@ietfa.amsl.com>; Mon, 3 Apr 2017 10:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.797
X-Spam-Level:
X-Spam-Status: No, score=-4.797 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 FZkHxf414Zlz for <unbearable@ietfa.amsl.com>; Mon, 3 Apr 2017 10:58:39 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0104.outbound.protection.outlook.com [104.47.40.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BD912946D for <unbearable@ietf.org>; Mon, 3 Apr 2017 10:58:39 -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=sr+RDtNbXw7FnTNyJLlYGuMnQJQuTcaB+5wFlq0KGVg=; b=X3ILblv35idBdccmhWsFRNoZw8TkSi9Pguhwn03bG3R3mec/+nfN2CZs+MGQqysK2lIc/FmJrqJW9dcFD0O7Qb0DNEJuvlzwjZ87Dmr704nXBF8xFfGlWZSBdPtzpwUDtQRmlkKh6+dvWhTHiKez96ArRuZdlUlqLH0Ur6cewxg=
Received: from SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) by SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.0; Mon, 3 Apr 2017 17:58:38 +0000
Received: from SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) by SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) with mapi id 15.01.1019.015; Mon, 3 Apr 2017 17:58:37 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Nick Sullivan <nicholas.sullivan@gmail.com>, "unbearable@ietf.org" <unbearable@ietf.org>
Thread-Topic: [Unbearable] Removing explicit public key crypto from Token Binding
Thread-Index: AQHSrCAeHzgU+tdKjkadVTeO7pYsxqGz6wVA
Date: Mon, 03 Apr 2017 17:58:37 +0000
Message-ID: <SN1PR21MB0096C6DB755979539128FC978C080@SN1PR21MB0096.namprd21.prod.outlook.com>
References: <CAOjisRyCx1RJ=2nJw_sVuJdh9f_ZdV+EF77MY4sM=wm20LXZVw@mail.gmail.com>
In-Reply-To: <CAOjisRyCx1RJ=2nJw_sVuJdh9f_ZdV+EF77MY4sM=wm20LXZVw@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:1::4ca]
x-microsoft-exchange-diagnostics: 1; SN1PR21MB0096; 7:qB8WD61AMnrplWmUNTDHB2pLSFvbykWaLxIvzOj7nL72i1W6Ms1p55Ve51ZSts0OABITAZxq1mt7KiEECZU7ldibE8eSQ5X/qFBszlCJXw10s7zXFaDgIXeZ1zKRkyH+M1FiH8MTLiOWFF6ygz5n3LcoOQ8/PJH8CdyrubgT2DITjJ+HmFc7DQCr9PYAz0pV/b0vKtzyegv7FaF5iitijVPJiXVr0pPGEmfzFAFav3HWWlr85Snlyo27FRgqJnOHEJY3WxZYphFz+sfGi971X1FGy0NFjz1vAvIHmiXa7hvGxJe9fSHIyjYIMhnPoFyVXKHn9bWP3FiB3NLRKB4OT1REMN8xRInFH6eWCxajJPg=
x-ms-office365-filtering-correlation-id: 246c0bc6-f618-426f-1100-08d47abb0e14
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR21MB0096;
x-microsoft-antispam-prvs: <SN1PR21MB0096ACD905BFBCEAA38EA5568C080@SN1PR21MB0096.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:SN1PR21MB0096; BCL:0; PCL:0; RULEID:; SRVR:SN1PR21MB0096;
x-forefront-prvs: 0266491E90
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39410400002)(39400400002)(39850400002)(3280700002)(6506006)(5660300001)(9686003)(53936002)(99286003)(8990500004)(2950100002)(8936002)(7696004)(5005710100001)(10290500002)(6306002)(54896002)(3660700001)(9326002)(6436002)(10090500001)(19609705001)(8676002)(77096006)(55016002)(2900100001)(7736002)(229853002)(81166006)(86362001)(6246003)(2501003)(6116002)(790700001)(74316002)(102836003)(76176999)(54356999)(50986999)(86612001)(39060400002)(189998001)(33656002)(2906002)(106356001)(38730400002)(122556002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR21MB0096; H:SN1PR21MB0096.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR21MB0096C6DB755979539128FC978C080SN1PR21MB0096namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 17:58:37.7407 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0096
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/jCO9uVwukEaRm1DrUG3YmM4fDqs>
Subject: Re: [Unbearable] Removing explicit public key crypto from Token Binding
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: Mon, 03 Apr 2017 17:58:42 -0000

Hi Nick,

Thanks for reviewing the Token Binding I-Ds; it’s never late to do this.


  *   The introduction of public key crypto at the application layer seems like a major downside to the current Token Binding Protocol draft.
The idea is for applications to use a Token Binding protocol implementation (a library, or a set of OS-provided APIs), rather than re-implementing public crypto in each app.


  *   Every new signature algorithm to be used here needs to be added to the new IANA registry. Every time this happens, this document needs to be updated. Which working group is responsible for updating drafts to add new algorithms or remove compromised ones once TOKBIND is over and we're discussing post-quantum signatures?
I’d expect that new signature schemes would be introduced by new I-Ds in the Tokbind WG, which by the way shows no sign of slowing down so far😊.


  *   This draft in particular is bound the semantics of several TLS extensions. Not only does the application need to know the result of the token binding extension, it needs to know whether or not the extended master secret has been used. Depending on the correct calculation of a master secret is an esoteric point that applications may forget to enforce.
The reason a TLS extension is used to negotiate Token Binding is that we would like to avoid extra round-trips.
Regarding EMS, arguably it’s a good idea to enforce it regardless on Token Binding…


  *   The basic idea is that the application provides a private key and certificate to the TLS library and the TLS library returns a binding of that certificate to the connection called an "exported authenticator".
The point of Token Binding is that the application does not have the private key. The private key is securely generated and stored, possibly in a hardware module.
Once the client has been authenticated (e.g., with TLS client auth and exported authenticators), the server may issue tokens for the client to use when connecting to this or other servers.
Token Binding makes it harder to export and replay such tokens.

Cheers,

Andrei