Subject: [Unbearable] Review of draft-ietf-tokbind-protocol-03

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Nov 2015 22:59:42 +0900

Hi.

As promised at the meeting, I’ve reviewed this document.

TL;DR version: I think this is ready for WGLC, but I would like the authors to consider a few remarks.

First, I’m not sure why the Introduction mentions the “web” and “user agent”. The protocol seems generic and fitting for anything running on top of TLS. While HTTP cookies and OAuth tokens are obvious use cases, I don’t think they are the only ones. And even the “web” is not limited to connection where the client is a “user agent” - web services are used by non-attended machines as well.

Binding identifiers: The introduction says (second paragraph "Such TLS Token Binding is identified by the corresponding public key”. A bit after that, it says "TLS Token Binding identifiers are never transmitted in clear text”. “Identifiers” are not mentioned earlier, so I assumed that the identifiers *are* public keys. The next paragraph mentions "Token Binding ID” which by context are the same as Token Binding identifiers. They are, but as it turns out in section 3 that TokenBindingID is not just the public key, but a structure that includes the public key along with a little more information. 

The third paragraph of the Introduction begins with "When issuing a security token to a client that supports TLS Token Binding, a server includes the client's TLS Token Binding ID in the token”  How is that done? Is the TokenBindingID structure included in the token? Or is it also acceptable to include it by reference (first 64 bits of the cookie is a key to a table of TokenBindingIDs). Similarly, how does the server, when presented with the security token (cookie) verify that the TokenBindingID matches the ID of the Token Binding established with the client?  IIUC the server just compares the TokenBindingID in the cookie to the one in the message.

So I would rewrite the 2nd and third paragraphs as follows:

OLD:
   A TLS Token Binding is established by the user agent generating a
   private-public key pair (possibly within a secure hardware module,
   such as TPM) per target server, and proving possession of the private
   key on every TLS connection to the target server.  The proof of
   possession involves signing the exported keying material [RFC5705]
   for the TLS connection with the private key.  Such TLS Token Binding
   is identified by the corresponding public key.  TLS Token Bindings
   are long-lived, i.e. they encompass multiple TLS connections and TLS
   sessions between a given client and server.  To protect privacy, TLS
   Token Binding identifiers are never transmitted in clear text and can
   be reset by the user at any time, e.g. when clearing browser cookies.

   When issuing a security token to a client that supports TLS Token
   Binding, a server includes the client's TLS Token Binding ID in the
   token.  Later on, when a client presents a security token containing
   a TLS Token Binding ID, the server makes sure the ID in the token
   matches the ID of the TLS Token Binding established with the client.
   In the case of a mismatch, the server discards the token.

NEW:
   A TLS Token Binding is established by the user agent generating a
   private-public key pair (possibly within a secure hardware module,
   such as TPM) per target server, by sending that public key to the 
   server in a TokenBindingID structure (see section 3), by the server
   issuing a security token to the client that includes this 
   TokenBindingID in full or by reference, and by the client proving
   possession of the private key on every TLS connection to the target 
   server.  The proof of possession involves signing the exported keying 
   material [RFC5705] for the TLS connection with the private key. The 
   TokenBindingID structure serves as an identifier for the TLS Token
   Binding.  To protect privacy, TLS Token Binding IDs are never 
   transmitted in clear text and can be reset by the user at any time, 
   e.g. when clearing browser cookies.

   Later on, when a client presents a security token containing
   a TLS Token Binding ID, the server makes sure that the ID in the 
   token matches the proof of possession in the message sent by the 
   client.  In the case of a mismatch, the server discards the token.

What do you think? 

I really liked the text in section 4. The place for a MUST (also support extended master secret) is in the regular text along with the reasoning. Pushing the detailed explanation to the security considerations is a great idea.

Section 5 repeats the TokenBindingID from section 3. Not sure that’s a good idea.

Section 8.3:  I don’t think the right recommendation is to not negotiate TokenBinding in in-private mode. This could be a way to fingerprint who is using in-private mode. A better idea IMO would be to generate fresh key pairs whenever the client enters in-private mode, and then destroy them as soon as the client exits this mode (and presumably restoring the regular database of key pairs).

Hope this helps

Yoav