Subject: [Unbearable] WGLC on draft-ietf-tokbind-protocol

From: Denis <[email-masked]>
Date: Wed, 21 Dec 2016 11:15:45 +0100

On November 31, 2016, I sent a message saying:

This set of documents failed to meet the terms of references of the WG 
charter.

It is not resistant to the ABC attack (Alice and Bob collusion attack).
In this attack Bob who is older than 18 colloborates with Alice and 
transmits a token to Alice
who is only 14 so that she can demonstrat to a RS that she is older than 18.

This kind of attack is not even mentionned in the security 
considerations section.

This set of documents should not be progressed to IETF last call unless 
the attack can be countered.

========================================================================

There are two options:

*Option A*: drop this series of documents, i.e. :

   draft-ietf-tokbind-protocol
   draft-ietf-tokbind-https
   draft-ietf-tokbind-negotiation

or *
*

*Option B*: clearly mention that the ABC attack cannot be countered 
using TLS binding.

In case, the latter decision would be taken by the WG, I propose a few 
text replacements.

Current Abstract: This document specifies Version 1.0 of the Token 
Binding protocol.The Token Binding protocol allows client/server 
applications to create long-lived, uniquely identifiable TLS [RFC5246 
<https://tools.ietf.org/html/rfc5246>] bindingsspanning multiple TLS 
sessions and connections.Applications arethen enabled to 
cryptographically bind security tokens to the TLS layer, preventing 
token export and replay attacks.To protectprivacy, the Token Binding 
identifiers are only transmitted encryptedand can be reset by the user 
at any time.Proposed replacementAbstract: This document specifies 
Version 1.0 of the Token Binding protocol. The Token Binding protocol 
allows client/server applications tocreate long-lived, uniquely 
identifiable TLS [RFC5246 <https://tools.ietf.org/html/rfc5246>] 
bindingsspanning multiple TLS sessions and connections.Applications 
arethen enabled to cryptographically bind security tokens to the 
TLSlayer. *However, the binding a security token to a TLS connection **is unable to counter collaboration attacks between two clients **since one client can compute the necessary information for the **other client without the need to release his key(s) to the other **client.For an effective protection against collaboration attacks, **an appropriate format of the security token, together with an **appropriate validation of some fields of it, must be used.*To protect 
privacy, the Token Binding identifiers are only transmitted encrypted 
and can be reset by the user at any time.

Current Introduction

(...) In order to successfully export and replay a bound security token, 
the attacker needs to also be able to export the client's privatekey, 
which is hard to do in the case of the key generated in a securehardware 
module.Proposed replacement

Introduction

(...) *In order to successfully export and replay a bound security 
token,**a client does not need to export the client's private**key, 
since it can perform all the necessary computations in the **case of a 
collaboration attack.*

Some other changes might need to be done in the same spirit. Denis