Subject: [Unbearable] -tokbind-protocol-04: version mismatch between negotiation and TB msg?

From: =JeffH <[email-masked]>
Date: Thu, 3 Mar 2016 19:01:39 -0800

Hi,

The TB ProtocolVersion and TokenBindingKeyParameters are negotiated in the 
TLS handshake as specified in -tokbind-negotiation-02, but there is no 
version indication in TokenBindingMessage (defined in tokbind-protocol-04 
aka TBPROTO).

Also, the criteria for incrementing the TB protocol version is not 
stipulated in either spec. Would the TB protocol version be incremented only 
due to changes to any of the structs defined in TBPROTO?

It seems that defining a TB extension would not necessitate a TB protocol 
version increment because TBPROTO says that impls must ignore extensions 
they do not understand.

However, what about if a new TokenBindingType is defined? I suppose that it 
could be side-stepped by stipulating that servers must ignore any 
TokenBindingMessage. TokenBinding.tokenbinding_type they do not understand. 
This is not presently stated AFAICT.

Also there are no stipulations in TBPROTO that the TokenBindingMessage MUST 
be of the same version negotiated at the TLS layer -- however, there are 
such stipulations wrt key parameters.

HTH,

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Fri, 25 Mar 2016 18:57:33 +0000

> The TB ProtocolVersion and TokenBindingKeyParameters are negotiated in the TLS handshake as specified in -tokbind-negotiation-02, but there is no version indication in TokenBindingMessage (defined in tokbind-protocol-04 aka TBPROTO).
Yes, the thinking is that you only get V1 TB message format if you negotiated TB V1, and that V2 will define what TB message looks like for V2 (either a different format or the same).

> Also, the criteria for incrementing the TB protocol version is not stipulated in either spec.
It seems that the decision to define a new TB protocol version could be motivated by a variety of reasons, many of them we may not be able to anticipate. Is it common for RFCs to stipulate criteria for incrementing the protocol version?

> Would the TB protocol version be incremented only due to changes to any of the structs defined in TBPROTO?
This would be a good reason, but not necessarily the only one. E.g. in the future we could decide to use something other than EKM, or EKM based on a different set of parameters, etc.

> It seems that defining a TB extension would not necessitate a TB protocol version increment because TBPROTO says that impls must ignore extensions they do not understand.
Correct; this is part of the reason why we have the extensions mechanism.

> However, what about if a new TokenBindingType is defined? I suppose that it could be side-stepped by stipulating that servers must ignore any TokenBindingMessage. TokenBinding.tokenbinding_type they do not understand. 
This is not presently stated AFAICT.
Good catch; I think an implementation should skip unknown TB types. Unless there are objections, I'll add text to this effect.

> Also there are no stipulations in TBPROTO that the TokenBindingMessage MUST be of the same version negotiated at the TLS layer -- however, there are such stipulations wrt key parameters.
Right, if we add a version indicator to the message, then it will make sense to require that it matches the negotiated TB version. I'd really like to stick to one message format per protocol version, therefore I'm not keen on message version indicators.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Thursday, March 3, 2016 7:02 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] -tokbind-protocol-04: version mismatch between negotiation and TB msg?

Hi,

The TB ProtocolVersion and TokenBindingKeyParameters are negotiated in the TLS handshake as specified in -tokbind-negotiation-02, but there is no version indication in TokenBindingMessage (defined in tokbind-protocol-04 aka TBPROTO).

Also, the criteria for incrementing the TB protocol version is not stipulated in either spec. Would the TB protocol version be incremented only due to changes to any of the structs defined in TBPROTO?

It seems that defining a TB extension would not necessitate a TB protocol version increment because TBPROTO says that impls must ignore extensions they do not understand.

However, what about if a new TokenBindingType is defined? I suppose that it could be side-stepped by stipulating that servers must ignore any TokenBindingMessage. TokenBinding.tokenbinding_type they do not understand. 
This is not presently stated AFAICT.

Also there are no stipulations in TBPROTO that the TokenBindingMessage MUST be of the same version negotiated at the TLS layer -- however, there are such stipulations wrt key parameters.

HTH,

=JeffH

_______________________________________________
Unbearable mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c11bb9dcbf26243fd621c08d343d955d8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=H5%2bibhlYMzYMhZpX4WKpcLcBUWHX7mIfZgslCR0hsyo%3d