Subject: [Unbearable] TLS extension: version field

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 16:50:44 +1000

This is getting a lot of use recently:

  https://www.imperialviolet.org/2016/05/16/agility.html

Specifically: "concentrate all extensibility in a single place and
actively defend it".

The version field in the TLS extension is a great example of exactly
the sort of field we should avoid on these grounds.  Why can't we just
use a new extension when it comes time to replace this protocol with
version 2?

---

From: Bill Cox <[email-masked]>
Date: Mon, 8 Aug 2016 08:35:18 -0700

> use a new extension when it comes time to replace this protocol with

Wouldn't that break version negotiation?  If the server supports only
version 1, and the client offers only version 2, is it possible to agree on
version 1?

We're using the major version as 0 for testing, and the minor version is
the version of the TB specification supported.  I currently reject all TB
connections below (0, 8), and this seems to be working well.  Given the
recent changes in the spec, the version numbers are quite helpful.  When we
support the 1.0 version, I plan to start rejecting 0 as the major version.

Maybe there is a better way to do this, but I'd prefer to keep the version
numbers for now.

Bill

---

From: Nick Harper <[email-masked]>
Date: Mon, 8 Aug 2016 10:52:07 -0700

I generally agree with Martin that the version field isn't needed and a new
TLS extension can be used when it's time for protocol version 2.

Version negotiation wouldn't be broken by this. A client would offer
whichever extensions it supports (so if it supports 1 and 2, it would send
the extensions for 1 and 2). This would have better version negotiation
properties than the existing mechanism. Under the new mechanism (separate
extension for versions 1 and 2), if a server sends an extension for either
version, it knows that the client supports that version. Right now, a
client could send version 2 in its extension, the server respond with
version 1, and end up with token binding not being negotiated because the
client doesn't support version 1 (but the server not knowing that until it
fails to receive a TokenBindingMessage).

Using the version number for draft versions has been useful for testing,
but we could easily use other mechanisms, like use a different (unassigned)
TLS extension number for each draft version, or send an extra extension
indicating the token binding extension version (like the TLS 1.3 draft
version extension).

On Mon, Aug 8, 2016 at 8:35 AM, Bill Cox <[email-masked]> wrote:

> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 8 Aug 2016 18:05:23 +0000

The use of separate TLS extensions for each TB version has a couple of undesirable properties:

1.      It’s wasteful on the wire: one would be duplicating TLS extension bytes and lists of TB key parameters. And this is in the ClientHello, where we care about size.

2.      Every time we come up with a new TB version, we need to specify a new TLS extension with its IANA number, etc.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Nick Harper
Sent: Monday, August 8, 2016 10:52 AM
To: Bill Cox <[email-masked]>
Cc: [email-masked]; Martin Thomson <[email-masked]>
Subject: Re: [Unbearable] TLS extension: version field

I generally agree with Martin that the version field isn't needed and a new TLS extension can be used when it's time for protocol version 2.

Version negotiation wouldn't be broken by this. A client would offer whichever extensions it supports (so if it supports 1 and 2, it would send the extensions for 1 and 2). This would have better version negotiation properties than the existing mechanism. Under the new mechanism (separate extension for versions 1 and 2), if a server sends an extension for either version, it knows that the client supports that version. Right now, a client could send version 2 in its extension, the server respond with version 1, and end up with token binding not being negotiated because the client doesn't support version 1 (but the server not knowing that until it fails to receive a TokenBindingMessage).

Using the version number for draft versions has been useful for testing, but we could easily use other mechanisms, like use a different (unassigned) TLS extension number for each draft version, or send an extra extension indicating the token binding extension version (like the TLS 1.3 draft version extension).

On Mon, Aug 8, 2016 at 8:35 AM, Bill Cox <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Aug 7, 2016 at 11:50 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
This is getting a lot of use recently:

Wouldn't that break version negotiation?  If the server supports only version 1, and the client offers only version 2, is it possible to agree on version 1?

We're using the major version as 0 for testing, and the minor version is the version of the TB specification supported.  I currently reject all TB connections below (0, 8), and this seems to be working well.  Given the recent changes in the spec, the version numbers are quite helpful.  When we support the 1.0 version, I plan to start rejecting 0 as the major version.

Maybe there is a better way to do this, but I'd prefer to keep the version numbers for now.

Bill

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Aug 2016 12:01:00 +1000

On 9 August 2016 at 04:05, Andrei Popov <[email-masked]> wrote:
> 1.      It’s wasteful on the wire: one would be duplicating TLS extension
> bytes and lists of TB key parameters. And this is in the ClientHello, where
> we care about size.

Yeah, I know that this costs, but if you move to that, it's 6-8 octets
right now, plus any more for EdDSA.  v2 might duplicate those octets,
but that's nothing when compared with the 70+ octets that a key share
in TLS 1.3 adds.

> 2.      Every time we come up with a new TB version, we need to specify a
> new TLS extension with its IANA number, etc.

Somehow, I don't think that's going to be a problem.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 9 Aug 2016 02:27:58 +0000

It's 6-8 bytes times the number of supported TB versions. In the TLS 1.3 discussion so far, we've not adopted the extension-based protocol version negotiation approach.

Also, the proposal requires that a TLS stack be updated for every new TB version, which is a real drawback. With the current TB negotiation extension, we can add new TB versions without changing TLS.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, August 8, 2016 7:01 PM
To: Andrei Popov <[email-masked]>
Cc: Nick Harper <[email-masked]>; Bill Cox <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] TLS extension: version field

On 9 August 2016 at 04:05, Andrei Popov <[email-masked]> wrote:
> bytes and lists of TB key parameters. And this is in the ClientHello, 
> where we care about size.

Yeah, I know that this costs, but if you move to that, it's 6-8 octets right now, plus any more for EdDSA.  v2 might duplicate those octets, but that's nothing when compared with the 70+ octets that a key share in TLS 1.3 adds.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Aug 2016 12:34:36 +1000

> Also, the proposal requires that a TLS stack be updated for every new TB version, which is a real drawback. With the current TB negotiation extension, we can add new TB versions without changing TL…

That's a problem that can be solved with software, if you care about
that sort of thing:
  tls.addGenericClientHelloExtension(id, blob);
  tls.addGenericServerHelloExtensionHandler(id, (blob) => {...});
  blob = tls.getGenericServerHelloExtension(id);

---

From: Andrei Popov <[email-masked]>
Date: Tue, 9 Aug 2016 16:49:39 +0000

The drawbacks of negotiating each TB version with a custom TLS extension:
1. More bytes in the ClientHello;
2. More IETF process when adding new TB versions;
3. TLS update for each TB version, or the need to add "generic TLS extension" support, putting the caller of the TLS stack in charge of handling (a subset of) TLS extensions.

The potential benefits:
a) Extensibility is concentrated in one place?
b) The server has a list of all client-supported TB versions in the ClientHello (this can be achieved within one TLS extension, if desired).

To me, these drawbacks outweigh the benefits, but I could live with either design.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, August 8, 2016 7:35 PM
To: Andrei Popov <[email-masked]>
Cc: Nick Harper <[email-masked]>; Bill Cox <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] TLS extension: version field

> Also, the proposal requires that a TLS stack be updated for every new TB version, which is a real drawback. With the current TB negotiation extension, we can add new TB versions without changing TL…

That's a problem that can be solved with software, if you care about that sort of thing:
  tls.addGenericClientHelloExtension(id, blob);
  tls.addGenericServerHelloExtensionHandler(id, (blob) => {...});
  blob = tls.getGenericServerHelloExtension(id);

---

From: Brian Campbell <[email-masked]>
Date: Tue, 9 Aug 2016 11:35:32 -0600

On Mon, Aug 8, 2016 at 11:52 AM, Nick Harper <[email-masked]> wrote:

>
> Right now, a client could send version 2 in its extension, the server
> respond with version 1, and end up with token binding not being negotiated
> because the client doesn't support version 1 (but the server not knowing
> that until it fails to receive a TokenBindingMessage).
>

I can't put my finger on exactly what issues might arise from this but it
does seem potentially problematic that unless the TB versions match exactly
in the TLS extensions, the sever can't know if the client will be doing
token binding until it receives (or doesn't) a TokenBindingMessage at the
application layer.

---

From: Nick Harper <[email-masked]>
Date: Tue, 9 Aug 2016 10:38:03 -0700

If we leave it as is, the version field is likely to ossify (like it has
with every version of SSL and TLS), so there's a decent chance that for
some implementations it won't work (a version intolerant server would
reject a client's v2 token binding negotiation, instead of falling back to
v1; separate extensions don't have this problem).
This version field also assumes that the only thing (apart from version
number) that needs to be negotiated is the key parameters. If a token
binding v2 is added, will it want to negotiate something else (and then
need a new TLS extension)?

I'm wondering what future changes to token binding might look like that
require bumping the protocol version number. I know that key attestation is
something that could potentially be added. My understanding is that this
would go in an Extension in the TokenBinding struct, and wouldn't need to
bump the protocol version number. For the protocol version number to be
changed, something would have to change the TokenBindingMessage format (or
the format of one of its fields). There's already a decent amount of
extensibility there in terms of key parameters, token binding types, and
extensions. Changing the signature to be of something besides the EKM value
is the only thing that comes to my mind that would fit in this format and
require changing the version number.

If more substantial changes are made to the TokenBindingMessage, I imagine
that changes will need to be made to negotiation to support those changes.
In that case, the version field in the current negotiation extension is
useless (a new extension will be needed for negotiating new things).

I think the likelihood that a change will be large enough to warrant a
change in protocol version number, yet small enough that negotiation
doesn't change, is fairly small. That, and the potential ossification of
the version field seem like good reasons to remove the version field and
use a new TLS extension number when the time comes.

On Tue, Aug 9, 2016 at 9:49 AM, Andrei Popov <[email-masked]>
wrote:

> 3. TLS update for each TB version, or the need to add "generic TLS
> extension" support, putting the caller of the TLS stack in charge of
> handling (a subset of) TLS extensions.
>
> The potential benefits:
> b) The server has a list of all client-supported TB versions in the
> ClientHello (this can be achieved within one TLS extension, if desired).
>
> > Also, the proposal requires that a TLS stack be updated for every new TB
> version, which is a real drawback. With the current TB negotiation
> extension, we can add new TB versions without changing TLS.
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 9 Aug 2016 12:43:43 -0600

I tend to agree with Martin and Nick's perspective here. Key parameters,
token binding types, and extensions already provide for a fair amount of
extensibility. One can't reliably predict the future but it seems more
likely than not that the first version of TB (which doesn't even exist yet)
could well have a nice long run before a new version is needed. A new
extension can be done if and when that time comes and working with existing
TLS extensions is much more likely to work in practice than a version
mechanism within the TB that wont really be exercised because there's only
one version. In meantime the client and server hello can use a few less
bytes (no version) in the ordinary case of negotiating the only version of
TB that exists (er, will exist soon).

On Tue, Aug 9, 2016 at 11:38 AM, Nick Harper <[email-masked]> wrote:

>> > Also, the proposal requires that a TLS stack be updated for every new
>> TB version, which is a real drawback. With the current TB negotiation

---

From: Andrei Popov <[email-masked]>
Date: Tue, 23 Aug 2016 16:59:26 +0000

From the practical standpoint, if we go with one TLS extension for each supported TB version, what TLS extension ID should we use to indicate support for the upcoming 0.9 draft?

Also, does Chrome already use the current early IANA assignment (24) to negotiate TB v0.8?

From: Brian Campbell [mailto:[email-masked]]
Sent: Tuesday, August 9, 2016 11:44 AM
To: Nick Harper <[email-masked]>
Cc: Andrei Popov <[email-masked]>; [email-masked]; Martin Thomson <[email-masked]>; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] TLS extension: version field

I tend to agree with Martin and Nick's perspective here. Key parameters, token binding types, and extensions already provide for a fair amount of extensibility. One can't reliably predict the future but it seems more likely than not that the first version of TB (which doesn't even exist yet) could well have a nice long run before a new version is needed. A new extension can be done if and when that time comes and working with existing TLS extensions is much more likely to work in practice than a version mechanism within the TB that wont really be exercised because there's only one version. In meantime the client and server hello can use a few less bytes (no version) in the ordinary case of negotiating the only version of TB that exists (er, will exist soon).

On Tue, Aug 9, 2016 at 11:38 AM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:
If we leave it as is, the version field is likely to ossify (like it has with every version of SSL and TLS), so there's a decent chance that for some implementations it won't work (a version intolerant server would reject a client's v2 token binding negotiation, instead of falling back to v1; separate extensions don't have this problem).
This version field also assumes that the only thing (apart from version number) that needs to be negotiated is the key parameters. If a token binding v2 is added, will it want to negotiate something else (and then need a new TLS extension)?

I'm wondering what future changes to token binding might look like that require bumping the protocol version number. I know that key attestation is something that could potentially be added. My understanding is that this would go in an Extension in the TokenBinding struct, and wouldn't need to bump the protocol version number. For the protocol version number to be changed, something would have to change the TokenBindingMessage format (or the format of one of its fields). There's already a decent amount of extensibility there in terms of key parameters, token binding types, and extensions. Changing the signature to be of something besides the EKM value is the only thing that comes to my mind that would fit in this format and require changing the version number.

If more substantial changes are made to the TokenBindingMessage, I imagine that changes will need to be made to negotiation to support those changes. In that case, the version field in the current negotiation extension is useless (a new extension will be needed for negotiating new things).

I think the likelihood that a change will be large enough to warrant a change in protocol version number, yet small enough that negotiation doesn't change, is fairly small. That, and the potential ossification of the version field seem like good reasons to remove the version field and use a new TLS extension number when the time comes.

On Tue, Aug 9, 2016 at 9:49 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

The potential benefits:

Cheers,

Andrei

---

From: Nick Harper <[email-masked]>
Date: Tue, 23 Aug 2016 10:52:12 -0700

Chrome is currently using the IANA assignment (24).

For draft 0.9, we could use an experimental TLS extension number, or we
could use 24 for TB, and send an additional extension to indicate the draft
version (like how TLS 1.3 is doing with 0xff02).

On Tue, Aug 23, 2016 at 9:59 AM, Andrei Popov <[email-masked]>
wrote:

> From the practical standpoint, if we go with one TLS extension for each
> supported TB version, what TLS extension ID should we use to indicate
> support for the upcoming 0.9 draft?
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Tuesday, August 9, 2016 11:44 AM
> *To:* Nick Harper <[email-masked]>
> *Cc:* Andrei Popov <[email-masked]>; [email-masked];
> Martin Thomson <[email-masked]>; Bill Cox <
> [email-masked]>
>
> *Subject:* Re: [Unbearable] TLS extension: version field
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 23 Aug 2016 18:24:22 +0000

So the proposal is to keep using TLS extension 24, and remove token_binding_version field?
Draft implementations will additionally supply another, private TLS extension TBD, that will contain the token_binding_version field?
Future TB versions will require new TLS extensions, in addition to the currently defined 24?

I don’t really like this, but trying to understand the suggested change in case I’m in the rough and the WG decides to go this way.

From: Nick Harper [mailto:[email-masked]]
Sent: Tuesday, August 23, 2016 10:52 AM
To: Andrei Popov <[email-masked]>
Cc: Martin Thomson <[email-masked]>; Bill Cox <[email-masked]>; Brian Campbell <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] TLS extension: version field

For draft 0.9, we could use an experimental TLS extension number, or we could use 24 for TB, and send an additional extension to indicate the draft version (like how TLS 1.3 is doing with 0xff02).

On Tue, Aug 23, 2016 at 9:59 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
From the practical standpoint, if we go with one TLS extension for each supported TB version, what TLS extension ID should we use to indicate support for the upcoming 0.9 draft?

From: Brian Campbell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 9, 2016 11:44 AM
To: Nick Harper <[email-masked]<mailto:[email-masked]>>
Cc: Andrei Popov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Bill Cox <[email-masked]<mailto:[email-masked]>>

The potential benefits:

Cheers,

Andrei

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Aug 2016 09:20:49 +1000

> version (like how TLS 1.3 is doing with 0xff02).

Why not use the current number until you make a breaking change (as I
suggested that you do), then let IANA have the number back and use a
new one each time you need to make a breaking change.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 23 Aug 2016 23:35:27 +0000

Because the last time we asked for a temporary IANA assignment, it took months. We need a version negotiation method that allows us to quickly implement and deploy TB drafts.  Until now, it has been the token_binding_version field in the token_binding extension.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, August 23, 2016 4:21 PM
To: Nick Harper <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Bill Cox <[email-masked]>; Brian Campbell <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] TLS extension: version field

On 24 August 2016 at 03:52, Nick Harper <[email-masked]> wrote:
> For draft 0.9, we could use an experimental TLS extension number, or 
> we could use 24 for TB, and send an additional extension to indicate 
> the draft version (like how TLS 1.3 is doing with 0xff02).

Why not use the current number until you make a breaking change (as I suggested that you do), then let IANA have the number back and use a new one each time you need to make a breaking change.

---

From: Nick Harper <[email-masked]>
Date: Tue, 23 Aug 2016 17:16:58 -0700

I don't think that trying to get a new IANA-assigned number for each draft
version that has breaking changes is a very practical approach.

On Tue, Aug 23, 2016 at 4:35 PM, Andrei Popov <[email-masked]>
wrote:

> Because the last time we asked for a temporary IANA assignment, it took
> months. We need a version negotiation method that allows us to quickly
> implement and deploy TB drafts.  Until now, it has been the
> token_binding_version field in the token_binding extension.
>
> Cheers,
>
> Andrei
>
> Cc: Andrei Popov <[email-masked]>; Bill Cox <
> [email-masked]>; Brian Campbell <[email-masked]>;
> [email-masked]
> suggested that you do), then let IANA have the number back and use a new
> one each time you need to make a breaking change.
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Aug 2016 10:42:07 +1000

> version that has breaking changes is a very practical approach.

Were you planning on breaking things often?

More seriously, most other user users of this space just grab a number
and use it.  Then they tell IANA when they finish with their
experiments.

If you think that you need to change more often, the new experimental
use space is probably a better idea.

---

From: Bill Cox <[email-masked]>
Date: Tue, 23 Aug 2016 21:35:54 -0700

I think I see a correlation here: those of us who have worked to build
functional token binding implementations would prefer not to throw the
cards in the air and with major changes, such as eliminating the version.
There are times for innovation, but near the end of a standardization
process is not one of them, IMO.  At this point, I would rather see
compatible bug-free implementations.  I'll throw my vote in with Nick and
Andrei for moving ahead without changing versioning.  It may not be
optimal, but it is good enough.  This is not an issue worth delaying the
roll-out of token binding.

Bill

---

From: Brian Campbell <[email-masked]>
Date: Wed, 24 Aug 2016 08:33:06 -0600

> Were you planning on breaking things often?
Well, to be fair here, you have proposed several breaking changes recently.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 24 Aug 2016 11:06:08 -0600

I shouldn't speak for him but, from previous statements in this thread, it
sounded like Nick is in favor of eliminating the version.

I do think that the question of eliminating the token_binding_version or
not should be considered independently of if/how the draft version can be
communicated for testing prior to the spec(s) finalizing.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 24 Aug 2016 17:13:58 +0000

Ø  I do think that the question of eliminating the token_binding_version or not should be considered independently of if/how the draft version can be communicated for testing prior to the spec(s) finalizing.
Sure, as long as we end up with a viable design that supports both experimentation and production deployment. And I don’t expect experimentation in this space to stop once TB 1.0 specs are published…

Cheers,

Andrei

From: Brian Campbell [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 10:06 AM
To: Bill Cox <[email-masked]>
Cc: Martin Thomson <[email-masked]>; Nick Harper <[email-masked]>; Andrei Popov <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] TLS extension: version field

I shouldn't speak for him but, from previous statements in this thread, it sounded like Nick is in favor of eliminating the version.
I do think that the question of eliminating the token_binding_version or not should be considered independently of if/how the draft version can be communicated for testing prior to the spec(s) finalizing.

On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox <[email-masked]<mailto:[email-masked]>> wrote:
I think I see a correlation here: those of us who have worked to build functional token binding implementations would prefer not to throw the cards in the air and with major changes, such as eliminating the version.  There are times for innovation, but near the end of a standardization process is not one of them, IMO.  At this point, I would rather see compatible bug-free implementations.  I'll throw my vote in with Nick and Andrei for moving ahead without changing versioning.  It may not be optimal, but it is good enough.  This is not an issue worth delaying the roll-out of token binding.

Bill

On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Nick Harper <[email-masked]>
Date: Wed, 24 Aug 2016 11:14:16 -0700

Brian is correct that I am generally in favor of removing the version field
from the extension. I think designing a system that works for production
deployment of the standardized spec takes precedence over experimentation
(but not to a point that would prevent experimentation). Earlier in the
thread I explained why the version field won't be useful for production
deployment of the standardized spec, and it's also possible to do
experimentation without the version field.

Andrei,
For experimenting after the TB 1.0 spec is published, you have the
extensions in the TokenBinding struct, which you can use without changing
the version number. If extensions aren't sufficient, then I think you'll
need something more in the negotiation message, meaning that you'll need a
new TLS extension anyway.

On Wed, Aug 24, 2016 at 10:13 AM, Andrei Popov <[email-masked]>
wrote:

> Ø  I do think that the question of eliminating the token_binding_version
> or not should be considered independently of if/how the draft version can
> be communicated for testing prior to the spec(s) finalizing.
>
> Sure, as long as we end up with a viable design that supports both
> experimentation and production deployment. And I don’t expect
> experimentation in this space to stop once TB 1.0 specs are published…
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *Sent:* Wednesday, August 24, 2016 10:06 AM
> *To:* Bill Cox <[email-masked]>
> *Cc:* Martin Thomson <[email-masked]>; Nick Harper <
> [email-masked]>; Andrei Popov <[email-masked]>;
> [email-masked]

---

From: Andrei Popov <[email-masked]>
Date: Wed, 24 Aug 2016 18:43:12 +0000

The current design is documented in the TBNEGO I-D; let’s get clarity on the competing proposal, so that we can get a consensus call on the mailing list and let the WG pick one option or the other.

My current understanding of the competing proposal is as follows (proponents please correct me if I got it wrong):

1.       Remove the token_binding_version field from the token_binding extension;

2.       Pick random unassigned a TLS extension IDs for each draft version;

3.       Finalized TB 1.0 will use a new IANA-assigned TLS extension code point other than 24 (because TLS extension 24 is currently used by Chrome, with token_binding_version in it).

From: Nick Harper [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 11:14 AM
To: Andrei Popov <[email-masked]>
Cc: Brian Campbell <[email-masked]>; Bill Cox <[email-masked]>; Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] TLS extension: version field

Brian is correct that I am generally in favor of removing the version field from the extension. I think designing a system that works for production deployment of the standardized spec takes precedence over experimentation (but not to a point that would prevent experimentation). Earlier in the thread I explained why the version field won't be useful for production deployment of the standardized spec, and it's also possible to do experimentation without the version field.

Andrei,
For experimenting after the TB 1.0 spec is published, you have the extensions in the TokenBinding struct, which you can use without changing the version number. If extensions aren't sufficient, then I think you'll need something more in the negotiation message, meaning that you'll need a new TLS extension anyway.

Cheers,

Andrei

From: Brian Campbell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 24, 2016 10:06 AM
To: Bill Cox <[email-masked]<mailto:[email-masked]>>
Cc: Martin Thomson <[email-masked]<mailto:[email-masked]>>; Nick Harper <[email-masked]<mailto:[email-masked]>>; Andrei Popov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Unbearable] TLS extension: version field

Bill

---

From: Nick Harper <[email-masked]>
Date: Wed, 24 Aug 2016 11:52:43 -0700

On Wed, Aug 24, 2016 at 11:43 AM, Andrei Popov <[email-masked]>
wrote:

> The current design is documented in the TBNEGO I-D; let’s get clarity on
> the competing proposal, so that we can get a consensus call on the mailing
> list and let the WG pick one option or the other.
>
>
>
> My current understanding of the competing proposal is as follows
> (proponents please correct me if I got it wrong):
>
We don't need to do this for every draft version, only those that make
breaking changes. (Of the past 8 drafts, I think there have been about 4
breaking changes.)

> 3.       Finalized TB 1.0 will use a new IANA-assigned TLS extension code
> point other than 24 (because TLS extension 24 is currently used by Chrome,
> with token_binding_version in it).
>
Chrome only sends 24 when the Token Binding experiment is enabled (it
defaults to off), so we can move to a new extension number for a draft
version (as in #2) and stop using 24. The only case where this could be a
problem is if someone manually flipped on TB and then doesn't update Chrome
(with automatic updates, this seems unlikely). I don't think we need a new
IANA assignment.

>
>
> *From:* Nick Harper [mailto:[email-masked]]
> *Sent:* Wednesday, August 24, 2016 11:14 AM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Brian Campbell <[email-masked]>; Bill Cox <
> [email-masked]>; Martin Thomson <[email-masked]>;
> [email-masked]
>
> Brian is correct that I am generally in favor of removing the version
> field from the extension. I think designing a system that works for
> production deployment of the standardized spec takes precedence over
> experimentation (but not to a point that would prevent experimentation).
> Earlier in the thread I explained why the version field won't be useful for
> production deployment of the standardized spec, and it's also possible to
> do experimentation without the version field.
>
>
>
> Andrei,
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 24 Aug 2016 19:06:52 +0000

Then the proposal seems to be as follows:

2.         Pick a random unassigned TLS extension ID for each TB draft that breaks compatibility;

3.         A TLS client can advertise multiple of these TLS extension IDs in the same ClientHello, the server has to pick no more than one;

4.         Finalized TB 1.0 will use the currently assigned TLS extension code point 24.

Is this summary correct?
Sent: Wednesday, August 24, 2016 11:53 AM

On Wed, Aug 24, 2016 at 11:43 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
The current design is documented in the TBNEGO I-D; let’s get clarity on the competing proposal, so that we can get a consensus call on the mailing list and let the WG pick one option or the other.

2.       Pick random unassigned a TLS extension IDs for each draft version;
We don't need to do this for every draft version, only those that make breaking changes. (Of the past 8 drafts, I think there have been about 4 breaking changes.)

3.       Finalized TB 1.0 will use a new IANA-assigned TLS extension code point other than 24 (because TLS extension 24 is currently used by Chrome, with token_binding_version in it).
Chrome only sends 24 when the Token Binding experiment is enabled (it defaults to off), so we can move to a new extension number for a draft version (as in #2) and stop using 24. The only case where this could be a problem is if someone manually flipped on TB and then doesn't update Chrome (with automatic updates, this seems unlikely). I don't think we need a new IANA assignment.

From: Nick Harper [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 24, 2016 11:14 AM
To: Andrei Popov <[email-masked]<mailto:[email-masked]>>
Cc: Brian Campbell <[email-masked]<mailto:[email-masked]>>; Bill Cox <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Andrei,

Cheers,

Andrei

Bill

---

From: Nick Harper <[email-masked]>
Date: Wed, 24 Aug 2016 12:12:24 -0700

Yes, that sounds right to me. Martin can correct if he was thinking of
something else.

On Wednesday, August 24, 2016, Andrei Popov <[email-masked]>
wrote:

> 3.         A TLS client can advertise multiple of these TLS extension IDs
> in the same ClientHello, the server has to pick no more than one;
>
> *From:* Nick Harper [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Sent:* Wednesday, August 24, 2016 11:53 AM
> *To:* Andrei Popov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc:* Brian Campbell <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Bill Cox <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Martin Thomson
> <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> On Wed, Aug 24, 2016 at 11:43 AM, Andrei Popov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> *From:* Nick Harper [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *To:* Andrei Popov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc:* Brian Campbell <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Bill Cox <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Martin Thomson
> <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>
>
> On Wed, Aug 24, 2016 at 10:13 AM, Andrei Popov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> *From:* Brian Campbell [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *To:* Bill Cox <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc:* Martin Thomson <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>; Nick Harper <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
> Andrei Popov <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> On 24 August 2016 at 10:16, Nick Harper <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Aug 2016 06:24:33 +1000

> Yes, that sounds right to me. Martin can correct if he was thinking of

That would work.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Aug 2016 21:29:40 +0100

Hi all,

> 2.         Pick a random unassigned TLS extension ID for each TB draft that breaks compatibility;

If this plan does garner consensus here, please verify it with the
TLS WG - those [1] are "their" codepoints after all.

Picking a random unassigned extension ID seems a bit smelly if
there's no range set aside for from which one can pick, which
I think is the case for [1].

If folks want to take that approach then the right thing to do
would be to get such a range assigned.

S.

[1]
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Aug 2016 17:38:16 -0300

For preproduction or experimental version is using the experimental space make sense and then use 24 for the RFC version?

We need something to use for interop testing.  

John B?
> On Aug 24, 2016, at 5:29 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi all,
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Aug 2016 21:45:40 +0100

> For preproduction or experimental version is using the experimental space make sense and then use 24 for the RFC version?

There's no experimental range set aside in that registry that
I can see. And folks have had issues with such, when it turns
out that a codepoint from the experimental range has "escaped"
into the wild to such an extent that nobody else could use it
to do experiments.

What I thought was being proposed here was a little different,
being to set aside a range from which random assignments of
still-free codepoints can be picked by this WG (or maybe this
or others) and where the randomly assigned codepoint might
turn into one that's permanently assigned later.

So one could propose either setting aside an experimental
range, or doing something new as in the paragraph above I
guess. Either way, getting that agreed on the TLS list would
be a good plan.

Cheers
S.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 25 Aug 2016 00:47:20 +0000

>> I think is the case for [1].
Yes, this is one of the concerns with the proposed scheme. And one of the reasons I would rather keep the current TB version negotiation mechanism.

> Either way, getting that agreed on the TLS list would be a good plan.
What do the Chairs think: should the proponents start the discussion on the TLS WG list, or should we gauge consensus in the TB WG first?

Cheers,

Andrei

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, August 24, 2016 1:46 PM
To: John Bradley <[email-masked]>
Cc: Andrei Popov <[email-masked]>; [email-masked]; Bill Cox <[email-masked]>; Brian Campbell <[email-masked]>; Martin Thomson <[email-masked]>; Nick Harper <[email-masked]>
Subject: Re: [Unbearable] TLS extension: version field

Cheers
S.

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Aug 2016 22:03:22 -0300

First we need to determine if there is consensus for a change.

Andrei can you sunrise the current state and options to the list.

Thanks.

John B.

On Aug 24, 2016 21:47, "Andrei Popov" <[email-masked]> wrote:

> Yes, this is one of the concerns with the proposed scheme. And one of the
> reasons I would rather keep the current TB version negotiation mechanism.
>
> What do the Chairs think: should the proponents start the discussion on
> the TLS WG list, or should we gauge consensus in the TB WG first?
>
> Cheers,
>
> Andrei
>
> Cc: Andrei Popov <[email-masked]>; [email-masked]; Bill
> Cox <[email-masked]>; Brian Campbell <[email-masked]>;
> Martin Thomson <[email-masked]>; Nick Harper <[email-masked]
> >
> > For preproduction or experimental version is using the experimental
> space make sense and then use 24 for the RFC version?
> >
>
> >> https://www.iana.org/assignments/tls-extensiontype-
> values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
> >>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 25 Aug 2016 02:02:15 +0000

Ø  Andrei can you sunrise the current state and options to the list.
Gladly.

What we have now:
Currently, TBNEGO-03<https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-03> states that the Token Binding protocol version is negotiated via the token_binding TLS extension (temporary IANA code point 24).
The client offers the highest supported TB protocol version, and the server responds with the lower of the TB protocol version offered by the client and the highest version supported by the server.

Pros:

-          Tried and tested mechanism, currently used by the draft implementations of TB.

-          Requires one TLS extension for all TB versions, until the hypothetical moment in the future, when the TB protocol changes so much that additional parameters need to be negotiated, other than protocol version and TB key parameters.

-          Token Binding protocol implementation can be upgraded independently of the TLS stack.

Cons:

-          When the server picks a TB protocol version lower than that offered by the client, the server does not know whether TB is negotiated, until the first application_data message is received.

-          Broken TB implementations might get TB version negotiation wrong, which would result in the client and server failing to negotiate TB.

Alternative proposal for TB WG consideration:

2.         Work with the TLS WG to set aside a range of TLS extension code points from which random assignments of still-free code points can be picked by the TB WG;

3.         Pick a random TLS extension code point from this range for each TB draft that breaks compatibility;

4.         A TLS client can advertise multiple of these TLS extension IDs in the same ClientHello, the server has to pick no more than one;

5.         IANA will eventually register one of these code points for use with the finalized TB 1.0.
Pros:

-          The client advertises all supported TB versions, so the server knows whether TB is negotiated after processing the ClientHello.

-          Some WG participants believe that this mechanism of TB version negotiation is less likely to become unusable due to broken implementations.

Cons:

-          Requires TLS WG to approve a range of TLS extension code points;

-          Uses a lot more bytes in the ClientHello, when multiple TB versions are advertised (because TB key parameters are duplicated in each extension).

-          TB implementation upgrade requires TLS stack upgrade or “generic TLS extension” support in the TLS stack (not generally available at the moment).

Cheers,

Andrei

From: John Bradley [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 6:03 PM
To: Andrei Popov <[email-masked]>
Cc: Brian Campbell <[email-masked]>; Bill Cox <[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

Thanks.

John B.

Cheers,

Andrei

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 24, 2016 1:46 PM
To: John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: Andrei Popov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Bill Cox <[email-masked]<mailto:[email-masked]>>; Brian Campbell <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Nick Harper <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] TLS extension: version field

Cheers
S.

>> On Aug 24, 2016, at 5:29 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>> Hi all,
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 25 Aug 2016 09:52:29 -0300

My personal preference is to stick with what we have now.  

Needing to mess with upgrading the TLS stack for token binding upgrades is going to be a major deployment hurdle.
Looking what it will take to get TB deployed in different environments and upgrades to the TLS stacks makes me hesitant to think that is going to work very often.
I suspect that we will find people lees likely to update versions in that case.

What do others think?

John B.

> On Aug 24, 2016, at 11:02 PM, Andrei Popov <[email-masked]> wrote:
> 
> Currently, TBNEGO-03 <https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-03> states that the Token Binding protocol version is negotiated via the token_binding TLS extension (temporary IANA code point 24).
> On Aug 24, 2016 21:47, "Andrei Popov" <[email-masked] <mailto:[email-masked]>> wrote:
> From: Stephen Farrell [mailto:[email-masked] <mailto:[email-masked]>]
> To: John Bradley <[email-masked] <mailto:[email-masked]>>
> Cc: Andrei Popov <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Bill Cox <[email-masked] <mailto:[email-masked]>>; Brian Campbell <[email-masked] <mailto:[email-masked]>>; Martin Thomson <[email-masked] <mailto:[email-masked]>>; Nick Harper <[email-masked] <mailto:[email-masked]>>
> >> On Aug 24, 2016, at 5:29 PM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >>
> >> Hi all,
> >>
> >> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 <https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> >
>

---

From: Bill Cox <[email-masked]>
Date: Thu, 25 Aug 2016 08:16:48 -0700

> 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

---

From: Andrei Popov <[email-masked]>
Date: Thu, 25 Aug 2016 17:07:40 +0000

It’s probably redundant of me to say this again☺, 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]<mailto:[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

---

From: Nick Harper <[email-masked]>
Date: Thu, 25 Aug 2016 10:21:03 -0700

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.
>
>
>
> Ø  Here is a simple question I need answered: Should Google turn on token
> 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]>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 25 Aug 2016 17:30:18 +0000

Ø  My gut feeling is that when we need a new TB version, we'll also need to change the extension…
Possibly, and this would be a good reason to introduce a new TLS extension for TB negotiation. IMHO, this hypothesis is not a good reason to remove the version field from the currently defined extension.

Ø  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.
This is possible as well, and it will be the 2nd good reason to introduce a new TLS extension. Keeping the version field in the current TB negotiation extension does not prevent us from negotiating TB 2.0 using a new TLS extension, right?

From: Nick Harper [mailto:[email-masked]]
Sent: Thursday, August 25, 2016 10:21 AM
To: Andrei Popov <[email-masked]>
Cc: Bill Cox <[email-masked]>; John Bradley <[email-masked]>; Brian Campbell <[email-masked]>; [email-masked]; Martin Thomson <[email-masked]>; Stephen Farrell <[email-masked]>; Leif Johansson <[email-masked]>
Subject: Re: [Unbearable] TLS extension: version field

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]<mailto:[email-masked]>> wrote:
It’s probably redundant of me to say this again☺, but I would rather keep the current negotiation mechanism, with the version field, especially at this point in the standards process.

>  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?

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 25, 2016 8:17 AM
To: John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: Andrei Popov <[email-masked]<mailto:[email-masked]>>; Brian Campbell <[email-masked]<mailto:[email-masked]>>; Nick Harper <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Stephen Farrell <[email-masked]<mailto:[email-masked]>>; Leif Johansson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] TLS extension: version field

What do others think?

John B.

Bill

---

From: Nick Harper <[email-masked]>
Date: Thu, 25 Aug 2016 10:40:25 -0700

On Thu, Aug 25, 2016 at 10:30 AM, Andrei Popov <[email-masked]>
wrote:

> Possibly, and this would be a good reason to introduce a new TLS extension
> for TB negotiation. IMHO, this hypothesis is not a good reason to remove
> the version field from the currently defined extension.
>
>
>
> Ø  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.
>
> This is possible as well, and it will be the 2nd good reason to introduce
> a new TLS extension. Keeping the version field in the current TB
> negotiation extension does not prevent us from negotiating TB 2.0 using a
> new TLS extension, right?
>

Correct. It seems weird to me that the final spec includes bytes that were
only used for developing the spec. I acknowledge that it's difficult to
remove them at this point, but maybe when we introduce the new extension
for a new TB version we can avoid this.

> *Sent:* Thursday, August 25, 2016 10:21 AM
> *Cc:* Bill Cox <[email-masked]>; John Bradley <[email-masked]>;
> Brian Campbell <[email-masked]>; [email-masked]; Martin
> Thomson <[email-masked]>; Stephen Farrell <
> [email-masked]>; Leif Johansson <[email-masked]>
>

---

From: Bill Cox <[email-masked]>
Date: Thu, 25 Aug 2016 10:50:50 -0700

> for a new TB version we can avoid this.

It seems weird to me, too.  We could save 1 of those bytes by saying that
the 1.0 version has a 1, and is not followed by the minor version number.
Since the byte after the version is the client's preferred key parameters,
it seems like we need the 1-byte separation.  I'd be OK with version 1.0
being represented by the single byte 0x01, and requiring all
implementations to reject TB extension 24 when the version byte is not 1.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Thu, 25 Aug 2016 18:14:16 +0000

Can be done, but do you really want to vary the token_binding extension format by draft vs. final version number, and test this code only to save 1 byte?

From: Bill Cox [mailto:[email-masked]]
Sent: Thursday, August 25, 2016 10:51 AM
To: Nick Harper <[email-masked]>
Cc: Andrei Popov <[email-masked]>; John Bradley <[email-masked]>; Brian Campbell <[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 10:40 AM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:

Correct. It seems weird to me that the final spec includes bytes that were only used for developing the spec. I acknowledge that it's difficult to remove them at this point, but maybe when we introduce the new extension for a new TB version we can avoid this.

It seems weird to me, too.  We could save 1 of those bytes by saying that the 1.0 version has a 1, and is not followed by the minor version number.  Since the byte after the version is the client's preferred key parameters, it seems like we need the 1-byte separation.  I'd be OK with version 1.0 being represented by the single byte 0x01, and requiring all implementations to reject TB extension 24 when the version byte is not 1.

Bill

---

From: Bill Cox <[email-masked]>
Date: Thu, 25 Aug 2016 12:27:18 -0700

On Thu, Aug 25, 2016 at 11:14 AM, Andrei Popov <[email-masked]>
wrote:

> Can be done, but do you really want to vary the token_binding extension
> format by draft vs. final version number, and test this code only to save 1
> byte?
>

I guess not.  My first preference would be to just keep the version field,
and kick the issue of whether to use it or not post-1.0 down the road.
However, if most people want to us to switch to using new extension numbers
rather than the version field, I'm OK with letting them do that, so long as
we do it in a way that does not slow down deployment.

Bill

---

From: Brian Campbell <[email-masked]>
Date: Fri, 26 Aug 2016 11:22:20 -0600

+1 FWIW

On Thu, Aug 25, 2016 at 11:21 AM, Nick Harper <[email-masked]> wrote:

> are fixed at (1,0) once the RFC is published.
>
>