Subject: Re: [Unbearable] TLS extension: version field

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Sep 2016 14:59:18 +1000

A solution that doesn't change implementations that exist is to mark
the version field as fixed and to define a new extension for the next
version.

On 26 August 2016 at 03:21, Nick Harper <[email-masked]> wrote:
> My gut feeling is that when we need a new TB version, we'll also need to
> change the extension, hence my preference for not having the version in the
> extension. However, the version field appears to be too useful for
> experimentation to remove it. Given that we're bikeshedding over 2 bytes per
> connection, I'm fine keeping it as is and taking the view the the bytes are
> fixed at (1,0) once the RFC is published. (If we leave the version in,
> there's going to be an implementation that only expects (1,0) and will
> reject TB for any other version. When this happens with TLS, we begrudgingly
> add a(n insecure) fallback, but I haven't figured out how to do that in this
> case.)
>
> On Thu, Aug 25, 2016 at 10:07 AM, Andrei Popov <[email-masked]>
> wrote:
>>
>> It’s probably redundant of me to say this againJ, but I would rather keep
>> the current negotiation mechanism, with the version field, especially at
>> this point in the standards process.
>>
>>
>>
>> In the future, if we see that the version field in the token_binding
>> extension is really causing problems with the deployment of a new TB
>> protocol version, we can design a new TLS extension.
>>
>>
>>
>> This way, we would only be applying the workaround when we actually have
>> to do so.
>>
>>
>>
>> Ø  Here is a simple question I need answered: Should Google turn on token
>> binding globally with the current version, or hold off until the 1.0
>> version?
>>
>> MS has the same issue: we’ve been planning to update our TB implementation
>> (which is currently based on the earliest TB drafts), but a new negotiation
>> mechanism would put these plans at risk.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: Bill Cox [mailto:[email-masked]]
>> Sent: Thursday, August 25, 2016 8:17 AM
>> To: John Bradley <[email-masked]>
>> Cc: Andrei Popov <[email-masked]>; Brian Campbell
>> <[email-masked]>; Nick Harper <[email-masked]>;
>> [email-masked]; Martin Thomson <[email-masked]>; Stephen
>> Farrell <[email-masked]>; Leif Johansson <[email-masked]>
>> Subject: Re: [Unbearable] TLS extension: version field
>>
>>
>>
>> On Thu, Aug 25, 2016 at 5:52 AM, John Bradley <[email-masked]> wrote:
>>
>>
>>
>> What do others think?
>>
>>
>>
>> John B.
>>
>>
>>
>> I agree.  I think this is the sort of thing we can fix in a new extension
>> in the future, a "token binding 2.0" extension.  I think the CONs are
>> over-stated, since sending the version field in 1.0 in no way restricts what
>> we do next.
>>
>>
>>
>> Here is a simple question I need answered: Should Google turn on token
>> binding globally with the current version, or hold off until the 1.0
>> version?  We've been assuming we want to go global now.  Are we wrong?
>>
>>
>>
>> I have token binding running on several dozen front-end machines,
>> processing a few million TB headers per day with solid reliability.  All I
>> have to do is change 2 lines in a config file to turn token binding on
>> globally.  Nick has to do something similar, plus some extensive process for
>> launching new Chrome features, and we'll have Chrome speaking TB from Chrome
>> to Google nearly everywhere.  If we make a binary incompatible change like
>> dropping the version field, we'll have to start the whole launch process
>> over again.  Each time loses at least a month, typically more like 2.
>>
>>
>>
>> My preference is for for this WG to agree that we hope to maintain binary
>> compatibility with the -08 version, so that I can turn on token binding
>> globally now.
>>
>>
>>
>> I would prefer to put upgrades like this on a list of "nice to have"
>> features.  Unless the list as a whole becomes compelling enough to break
>> compatibility with the -08 version, I think we should launch 1.0 in a -08
>> compatible way.
>>
>>
>>
>> BTW, this is not a minor change.  As a custom extension, I'll have to have
>> multiple callbacks in the client hello append successful version numbers
>> negotiated to a vector, and in the callbacks for the server hello, I'll have
>> to pick the best negotiated version and block all the rest, probably using a
>> single callback used for each version that disables itself after being
>> called once.  Then, I'll have to write tests for all the possible
>> combinations of versions that could be processed (Google takes testing
>> pretty seriously in the front-end group).  It is not rocket science, but
>> given the review process here, and how we like core changes to bake for a
>> while, it will be a few weeks before I can get this change onto live
>> front-end machines.
>>
>>
>>
>> Bill
>
>