Re: [Unbearable] Possible attack on Token Binding with RSA key exchange

Andrei Popov <> Mon, 04 September 2017 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F9C6132193 for <>; Mon, 4 Sep 2017 15:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.811
X-Spam-Status: No, score=-2.811 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 uWJfdvXX6sgT for <>; Mon, 4 Sep 2017 15:59:32 -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 A94E8132192 for <>; Mon, 4 Sep 2017 15:59:32 -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=OCNTMZt0/Kl9RoABxQfCybHBd0u2x0ZtVAgvmJlPr/k=; b=EpzPfpdzZlYjnTcdY8XGrPK4EOOm8SNg7sEdWpuR70AuGx3cMidaPbWfBj7+mnUUUJg5FS5mphtt0RAHIFsMzTiEslgHSDNRvST+f95dzUFdWArG4OcVMw8RATJaVSg0Pe7wT29hre2Ir9tvu7Teo0QZ+Dd/g2GoTA949TuWNFE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Mon, 4 Sep 2017 22:59:31 +0000
Received: from ([]) by ([]) with mapi id 15.20.0056.000; Mon, 4 Sep 2017 22:59:31 +0000
From: Andrei Popov <>
To: Subodh Iyengar <>, Nick Harper <>, IETF Tokbind WG <>
Thread-Topic: [Unbearable] Possible attack on Token Binding with RSA key exchange
Thread-Index: AQHTI248h15PeY9U802Z73g90LEOZ6Kgm0WAgAABCgCABLlR4A==
Date: Mon, 04 Sep 2017 22:59:30 +0000
Message-ID: <>
References: <>, <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e8:1::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0136; 6:zS9MUu2jMG55dVI2v0IEZAHFWKw3yqvziKY/K9ZQDgYi7AHeuQ8CuXnpUYZMvSVOFAFf44dXHEZ/YUNlJx0TMiSDUn0A+yYQ6GciK5sInyKdwzqKkSHXNI2kw85RAGjOvKNZY/G7tYIdJNgehsKTZtamsz/3MXeiTS0T2r08bCIDmPI304E319NZQP+wMaLbmbbDWWqIpz/nq2LmQezCUhPb0GYKBU/hKh52Sh0LLmPtAEWUh307ny+bX4DpB/B0yqm/sHUlKzqvJfOQF9gqeZYj1w2xXHLmfV9kWhQhIi3uh6qNnJpFpZf8th//T4wg2Dk2BIaybidbcMzzmnrr/w==; 5:HwpQ886OQn6JAG6rv3BprtXhZR6d5Gfb6mOr5r/THAEtwOMKE7IXGm0LAG+xXOj0e9iXPnAZ8/NWtcjuT2fEhC8PXA3dnhI8gXNWkXr3Uaz8eSPMMq9tHIl+uSqTmnbDyoRFujvsXRvybwQlydBOyw==; 24:zDa/yf25rGqfA1ArzGhupHOGDNjkBM8XRAFtUKndrF0z4MbBvUzEK8NiVE/ufYl1HJeQnJXIi2+ac/7QwBc5FkA86Hz2yYCjn4oZ8hoMdX0=; 7:i4xIMuHeN7nxs16/q9jv/L2LC6kCdtUo4iBdBhS4jPXHH02kYFkNbLcuPGUV7UCPDRcsMMLxVqhiZCM1P4qFgyPFnrNfI6zNvASGviBV3xuiidiWN4gGa3j4Uobq6wI91yO2xM/h5QwCepr2gymkr2yatJPA7eDhqA+vzFXbJLbCP6G74sPtnq5drRDA+48hyRUEZgT132rE+bWmN9nu/a+1aKvRTGSBpsuZJ8n2TMM=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 86ce12ac-0473-4f6e-ed4f-08d4f3e89a22
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0136;
x-ms-traffictypediagnostic: CY4PR21MB0136:
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705)(189930954265078)(211936372134217)(153496737603132)(219752817060721)(21748063052155);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(920507026)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0136; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0136;
x-forefront-prvs: 0420213CCD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(47760400005)(377454003)(189002)(199003)(105586002)(106356001)(7696004)(53546010)(54356999)(575784001)(606006)(72206003)(229853002)(8936002)(966005)(86612001)(81166006)(81156014)(8676002)(68736007)(19609705001)(76176999)(97736004)(5660300001)(10090500001)(50986999)(33656002)(86362001)(14454004)(6506006)(6436002)(6306002)(99286003)(54896002)(6246003)(77096006)(2950100002)(6116002)(790700001)(102836003)(478600001)(2906002)(34040400001)(3660700001)(25786009)(74316002)(7736002)(5005710100001)(9686003)(189998001)(101416001)(10290500003)(8990500004)(236005)(53936002)(3280700002)(2900100001)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0136;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0120ED0B8619A2960F3462368C910CY4PR21MB0120namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2017 22:59:30.8931 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0136
Archived-At: <>
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange
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: Mon, 04 Sep 2017 22:59:35 -0000

It seems clear that binding tokens to broken TLS channels does one no good, but I don't mind adding some statements to this effect in the security considerations.
The statements would need to be general enough to cover TLS client and server compromise, PFS and non-PFS.

Nick, please feel free to author a PR. If we get to IESG review someday, there will be more edits, and we can incorporate this as well.

I don't think it makes sense to limit TB to (EC)DHE, especially if we're going to allow TB in combination with TLS 1.3 0-RTT mode.



From: Unbearable [] On Behalf Of Subodh Iyengar
Sent: Friday, September 1, 2017 3:28 PM
To: Nick Harper <>; IETF Tokbind WG <>
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange

Having said that, even if we only support forward secure ciphers, I do not think we can reasonably claim that we are secure against the threat of stolen private keys.

I like the the carrot opportunity this brings to encourage adoption of forward secure cipher suites.


From: Subodh Iyengar
Sent: Friday, September 1, 2017 3:24:25 PM
To: Nick Harper; IETF Tokbind WG
Subject: Re: [Unbearable] Possible attack on Token Binding with RSA key exchange

+1 to requiring that token binding only be used with forward secure cipher suites.

I believe the extended master secret requirement of token binding prevents the attack on forward secure suites, i.e. an attacker cannot change the DH share advertised by the real server and thus needs to get the private key for it.


From: Unbearable <<>> on behalf of Nick Harper <<>>
Sent: Friday, September 1, 2017 3:03:37 PM
To: IETF Tokbind WG
Subject: [Unbearable] Possible attack on Token Binding with RSA key exchange

I came across an attack on Token Binding today, which I think is worth
addressing in TBPROTO in some fashion (likely another paragraph in
Security Considerations). This attack involves an adversary with the
private key of a server it wishes to impersonate, and was mentioned in
draft-balfanz-tls-channelid in the last paragraph of its Security

In brief, if an attacker has possession of a server's private key, it
can hijack a TLS connection between client and server if the
connection uses RSA key exchange instead of (EC)DHE key exchange,
which allows the attacker to exercise the bound token without
possession of the Token Binding private key.

I realize that we're past WGLC at this point, but I think this should
be addressed. On one end, we could require forward-secret key exchange
modes with Token Binding. We could also describe this specific attack
in the Security Considerations, or we could expand the Security
Considerations to describe what attacks are and aren't in the Token
Binding threat model, to say that attacks where the adversary has the
server's private key are out of scope.

Unbearable mailing list<><>