Re: [Gen-art] Gen-ART Telechat review of draft-ietf-tokbind-negotiation-11

[Andrei Popov <[e-mail]>]

Hi Paul,

Thanks for the feedback.

> These don't state the precise meaning of "highest valued version".
I can clarify that the "highest valued version" means the version with the highest major and minor numbers that the client supports. Would this be clear?

> For example, if the supplied version is 3.5, what does it say about other versions supported?
As noted earlier, the client advertising version 3.5 says precisely nothing about client support for any other TB versions.
The draft currently says:
" If the client does not support the Token Binding protocol version selected by the server, then the connection proceeds without Token Binding."
I suggest the following additional language to make this clearer:
"There is no requirement for the client to  support any Token Binding versions other than the one advertised in the client's "token_binding" extension."

Cheers,

Andrei

-----Original Message-----
From: Paul Kyzivat <[e-mail]> 
Sent: Wednesday, April 18, 2018 11:43 AM
To: [e-mail]
Cc: General Area Review Team <[e-mail]>
Subject: Gen-ART Telechat review of draft-ietf-tokbind-negotiation-11

For IESG Evaluation reviews: I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.tools.ietf.org%2Farea%2Fgen%2Ftrac%2Fwiki%2FGenArtfaq&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cad6baf98fd364362af4d08d5a55c3e76%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636596737964819391&sdata=ug6ZiXYW6CXh0ViezKpf%2FrqS2BabpHCd6tHS%2B23yWv8%3D&reserved=0>.

Document: draft-ietf-tokbind-negotiation-11
Reviewer: Paul Kyzivat
Review Date: 2018-04-18
IETF LC End Date: 2017-11-27
IESG Telechat date: 2018-05-08

Summary:

This draft is on the right track but has open issues, described in the review.

Issues:

Major: 0
Minor: 1
Nits:  0

(1) MINOR:

Section 2 states the following requirement:

     ... it SHOULD
     indicate the latest (highest valued) version in
     TokenBindingParameters.token_binding_version.

Section 4 states:

    The client receiving the "token_binding" extension MUST terminate the
    handshake with a fatal "unsupported_extension" alert if any of the
    following conditions are true:

    ...

    2.  "token_binding_version" is higher than the Token Binding protocol
        version advertised by the client.

These don't state the precise meaning of "highest valued version". For example, if the supplied version is 3.5, what does it say about other versions supported? Presumably it covers 3.0...3.5. But what about lower major versions? I guess it must mean that 1.0...1.x and 2.0...2.y are also supported for some value of x and y. But *what* values of x and y? 
All that were ever defined? And what are the rules about versions 0.n?

This use of versioning implies that a particular discipline be followed for defining new major/minor version numbers, and for implementors. But no such discipline is described.

Additional text is needed to nail all of this down.

The above restates what I included in my Last Call review of -10. In followup to that I had some discussion with the author about this but we didn't reach agreement. The author replied to me that:

"Similarly to TLS <= 1.2 version negotiation, this says nothing about any other protocol versions supported by the client. It only means that the server may respond with version X.Y where X<=3 and Y<=5. If the client happens to not support the version the server has chosen, the client will not use Token Binding on this connection."

I'm not familiar with TLS version negotiation, but I just peeked at TLS
1.2 and 1.3. I found the following from TLS 1.3 enlightening:

    -  The TLS 1.2 version negotiation mechanism has been deprecated in
       favor of a version list in an extension.  This increases
       compatibility with existing servers that incorrectly implemented
       version negotiation.

Apparently the TLS 1.2 version negotiation isn't a very good one to follow in this regard. Enumerating supported versions is more robust.

In any case this document doesn't have any text to state that the version negotiation should be the same as TLS 1.2.

So I continue to suggest that the complete mechanism for negotiating the version be specified.