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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
