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

[Paul Kyzivat <[e-mail]>]

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 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.