Subject: [Unbearable] Mismatches between negotiated version and TB header format

From: Bill Cox <[email-masked]>
Date: Tue, 13 Dec 2016 08:29:03 -0800

Approximately 1% of the token binding requests hitting Google, after
negotiating version 0.10, have an out-of-date token-binding header format.
They come from multiple companies and a variety of products.  Vin and I
looked into these, and IMO it looks like this is going to be a bit of an
ongoing headache for token binding.

The problem is that most current implementations bury token-binding
negotiation way down in the SSL layer, while token-binding headers are
generated in a higher-level HTTP library.  Unfortunately, it is very easy
for these to get out of sync.  The SSL layer often has security updates
independently of the HTTP library, so it is common to see quite new SSL
libraries under quite old HTP libraries.

One way to deal with this is to use a common library for both token-binding
negotiation and header generation/parsing.  This is in theory simple to
do.  However, at large companies, this can be difficult.  In particular,
the OpenSSL custom-extension API is not usually exported into typical C++,
Java, or C# wrappers, and direct access to the SSLContext object is often
not permitted.  This means that token-binding negotiation has to be built
into the lower level library, which does not generally export functions
like generate/parse token-binding headers.

This problem will get worse if we switch to native baked-in token-binding
negotiation in OpenSSL and other libraries.  I do not have a good solution
to propose for this.  Some ideas are:

- bury the whole token-binding library down in the network stack, and
export token-binding classes.
- have networking libraries export custom extension APIs.
- have token-binding HTTP libraries compare their version against the
negotiated version
- add the token-binding version to headers so that servers can detect the
mismatch more easily

Thoughts?

Bill

---

From: Andrei Popov <[email-masked]>
Date: Tue, 13 Dec 2016 18:30:42 +0000

To me, this is more of a growth problem that we’ll get over once there is an RFC.

E.g. there were some internal Windows builds that advertised 0.8, but sent 0.2 TB messages, because it was more convenient for us to sequence TB update this way.
These builds are not intended for production use, and self-hosters did not suffer from this, because there were no TB servers at the time, except for test deployments.
Going forward, these builds simply get phased out of circulation. And if they fail to connect to sites, they’ll disappear sooner.

Either of the proposed solutions work, but I think it’s up to the implementation to choose which approach is best for them.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Tuesday, December 13, 2016 8:29 AM
To: Tokbind WG <[email-masked]>
Subject: [Unbearable] Mismatches between negotiated version and TB header format

Approximately 1% of the token binding requests hitting Google, after negotiating version 0.10, have an out-of-date token-binding header format.  They come from multiple companies and a variety of products.  Vin and I looked into these, and IMO it looks like this is going to be a bit of an ongoing headache for token binding.

The problem is that most current implementations bury token-binding negotiation way down in the SSL layer, while token-binding headers are generated in a higher-level HTTP library.  Unfortunately, it is very easy for these to get out of sync.  The SSL layer often has security updates independently of the HTTP library, so it is common to see quite new SSL libraries under quite old HTP libraries.

One way to deal with this is to use a common library for both token-binding negotiation and header generation/parsing.  This is in theory simple to do.  However, at large companies, this can be difficult.  In particular, the OpenSSL custom-extension API is not usually exported into typical C++, Java, or C# wrappers, and direct access to the SSLContext object is often not permitted.  This means that token-binding negotiation has to be built into the lower level library, which does not generally export functions like generate/parse token-binding headers.

This problem will get worse if we switch to native baked-in token-binding negotiation in OpenSSL and other libraries.  I do not have a good solution to propose for this.  Some ideas are:

- bury the whole token-binding library down in the network stack, and export token-binding classes.
- have networking libraries export custom extension APIs.
- have token-binding HTTP libraries compare their version against the negotiated version
- add the token-binding version to headers so that servers can detect the mismatch more easily

Thoughts?

Bill