Subject: [Unbearable] Token Binding extension has incorrect size for key array

From: Bill Cox <[email-masked]>
Date: Sat, 29 Aug 2015 12:46:25 -0700

The spec <https://tools.ietf.org/id/draft-popov-tokbind-negotiation-00.txt>
and used a uint16 for the length of the key type array, but the keys are
8-bit values and are not allowed to repeat.  This is clearly an error in
the spec.  I used a 1-byte length instead.  No point wasting a byte :)

Two other issues in this spec:

1) The server has to ignore this extension if the client broadcasts support
for a newer version than the server knows about.  This will result in Token
Binding being disabled whenever the client supports a newer version than
the server, or alternatively, clients will have to be careful to only
broadcast older well supported versions.  This should probably be a range
of versions rather than just one.  My preference is to simplify the version
number to 1 byte ,and send a 2-byte range.  0 would be the prototype
version, and 1, would be the first official version.  The server would pick
a version from the range sent by the client and send the same version
repeated (so that server and client headers are the same size).  I do not
think we need a 2-byte version for this simple extension.  Every byte
counts :)

2) The server currently has no way to inform the client what it's
preferences are.  Instead, the server has to pick just one.  In the case
where the server prefers ECDSA, but the client already has an RSA key pair,
the server is likely to pick ECDSA, invalidating the client's key pair.
Instead, I send a list of acceptable parameters both ways, in order of
preference, where the server sends a subset of the list received from the
client.  This allows the client to know that the server prefers ECDSA but
is willing to continue support for RSA, and the client can choose to
continue using the new key or not.

Thanks,
Bill

---

From: Andrei Popov <[email-masked]>
Date: Mon, 31 Aug 2015 19:32:25 +0000

Hi Bill,

1) I brought this up for discussion in Prague and the group seemed to have no interest in a more elaborate version negotiation mechanism. If enough people are interested in reopening this conversation, sure we can come up with a range of versions, a list of versions, or a TLS-style “highest supported version” mechanism.
2) This was the 2nd point I brought up in Prague. Again, consensus in the room was to keep negotiating only one algorithm (but to allow the client send other types of keys in the federation case).

Perhaps it would be useful to make consensus calls on the mailing list, to confirm (or overturn) the decisions made in Prague?

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Saturday, August 29, 2015 12:46 PM
To: [email-masked]
Cc: Nick Harper <[email-masked]>
Subject: [Unbearable] Token Binding extension has incorrect size for key array

The spec<https://tools.ietf.org/id/draft-popov-tokbind-negotiation-00.txt> and used a uint16 for the length of the key type array, but the keys are 8-bit values and are not allowed to repeat.  This is clearly an error in the spec.  I used a 1-byte length instead.  No point wasting a byte :)

1) The server has to ignore this extension if the client broadcasts support for a newer version than the server knows about.  This will result in Token Binding being disabled whenever the client supports a newer version than the server, or alternatively, clients will have to be careful to only broadcast older well supported versions.  This should probably be a range of versions rather than just one.  My preference is to simplify the version number to 1 byte ,and send a 2-byte range.  0 would be the prototype version, and 1, would be the first official version.  The server would pick a version from the range sent by the client and send the same version repeated (so that server and client headers are the same size).  I do not think we need a 2-byte version for this simple extension.  Every byte counts :)

2) The server currently has no way to inform the client what it's preferences are.  Instead, the server has to pick just one.  In the case where the server prefers ECDSA, but the client already has an RSA key pair, the server is likely to pick ECDSA, invalidating the client's key pair.  Instead, I send a list of acceptable parameters both ways, in order of preference, where the server sends a subset of the list received from the client.  This allows the client to know that the server prefers ECDSA but is willing to continue support for RSA, and the client can choose to continue using the new key or not.

Thanks,
Bill

---

From: Bill Cox <[email-masked]>
Date: Mon, 31 Aug 2015 12:44:36 -0700

On Mon, Aug 31, 2015 at 12:32 PM, Andrei Popov <[email-masked]>
wrote:

> Hi Bill,
>
>
>
> 1) I brought this up for discussion in Prague and the group seemed to have
> no interest in a more elaborate version negotiation mechanism. If enough
> people are interested in reopening this conversation, sure we can come up
> with a range of versions, a list of versions, or a TLS-style “highest
> supported version” mechanism.
>
> 2) This was the 2nd point I brought up in Prague. Again, consensus in the
> room was to keep negotiating only one algorithm (but to allow the client
> send other types of keys in the federation case).
>
>
>
> Perhaps it would be useful to make consensus calls on the mailing list, to
> confirm (or overturn) the decisions made in Prague?
>
>
>
> Cheers,
>
>
>
> Andrei
>

As an implementer, I would appreciate tentative decisions on the list,
since I'm currently writing the code.

Thanks,
Bill

---

From: Andrei Popov <[email-masked]>
Date: Mon, 31 Aug 2015 19:52:53 +0000

<+ Chairs>

Yes, unless I missed it, the tentative decisions/minutes from Prague were not published on the unbearable mailing list.

From: Bill Cox [mailto:[email-masked]]
Sent: Monday, August 31, 2015 12:45 PM
To: Andrei Popov <[email-masked]>
Cc: [email-masked]; Nick Harper <[email-masked]>
Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array

On Mon, Aug 31, 2015 at 12:32 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bill,

Cheers,

Andrei

As an implementer, I would appreciate tentative decisions on the list, since I'm currently writing the code.

Thanks,
Bill

---

From: Nick Harper <[email-masked]>
Date: Mon, 31 Aug 2015 13:24:04 -0700

>From the client side implementation perspective, I would be in favor of
version negotiation including a list or range of supported versions. With
the current approach, the client can only support one version, and if it
updates to support a newer version, it would break compatibility with
servers still running the older version if the client switches too soon.

> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Bill
> Cox
> *Sent:* Saturday, August 29, 2015 12:46 PM
> *To:* [email-masked]
> *Cc:* Nick Harper <[email-masked]>
> *Subject:* [Unbearable] Token Binding extension has incorrect size for
> key array
>
>
>
> The spec
> <https://tools.ietf.org/id/draft-popov-tokbind-negotiation-00.txt> and
> used a uint16 for the length of the key type array, but the keys are 8-bit
> values and are not allowed to repeat.  This is clearly an error in the
> spec.  I used a 1-byte length instead.  No point wasting a byte :)
>
>
>
> 1) The server has to ignore this extension if the client broadcasts
> support for a newer version than the server knows about.  This will result
> in Token Binding being disabled whenever the client supports a newer
> version than the server, or alternatively, clients will have to be careful
> to only broadcast older well supported versions.  This should probably be a
> range of versions rather than just one.  My preference is to simplify the
> version number to 1 byte ,and send a 2-byte range.  0 would be the
> prototype version, and 1, would be the first official version.  The server
> would pick a version from the range sent by the client and send the same
> version repeated (so that server and client headers are the same size).  I
> do not think we need a 2-byte version for this simple extension.  Every
> byte counts :)
>
>
>