[dward]

A couple corrections to the section on token binding:

1. It works on all TLS connections, not just mTLS connections. It even works on unauthenticated TLS (although I wouldn't advise forgoing server authentication). That's the beauty of key binding the token. It's useless without the key.

2. It's unclear what the tokbind noun refers to in this paragraph. I'm going to assume that you are just referring to the token binding. A token binding lasts for the duration of a TLS connection (sans renegotiation and resumption which complicate things) and is derived from the [clientrandom,serverrandom,mastersecret] of the connection. The token binding secret is just an RSA or ECDSA keypair, independent of client or server certificates, that is generated when the token is issued. The token is bound to the keypair (e.g. by a hash of the public key that's stored in a JWT claim or stored in a database table keyed by an opaque oauth token).

3. Anyone can use token binding, not just members of the IETF TLS working group :)

[tptacek]

I'm fuzzy on token binding versus channel ID, the preceding (and, to my eyes, more useful) extension. In neither case do I anticipate widespread use. But it's good to know that it's there.

[dward]

Token binding changed a few things as it evolved from origin bound certificates, notably:

* moving from using client certs to signing exported keying material[0] to prove key possession

* adding support for RSA keys

* adding support for multiple token bindings on a single connection (see referred token binding)

Fundamentally the two are very similar. I'm curious as to why you think origin bound certificates are more useful.

> In neither case do I anticipate widespread use

For the browser case:

* 0-RTT in TLS 1.3 (and resumption in general) negate a lot of the benefits of token binding. Big players aren't going to give this up (see QUIC).

* Hardware bound keys are interesting, but if crypto oracles are available on consumer machines, they are often far to slow to be used practically.

* Many compromises happen in the browser so token binding only marginally improves the security of cookies.

I think it will fall out of favor there. The service to service use case is an interesting one. If you turn off 0-RTT and session resumption, and bind tokens to hardware, the security properties start to look a lot like hardware bound mTLS. If the tooling ever gets developed, it might turn out to be a leaner alternative to a full blown PKI.

[0]: https://tools.ietf.org/html/rfc5705