The working group has discussed this approach to version negotiation a number of times.
This is the result of a concensus decision by the work group that has held for some time. We should certainly clarify the spec where possible, but changing negotiation at this point seems unlikely to get any backing in the WG. Regards John B. > On Apr 30, 2018, at 7:00 PM, Andrei Popov <andrei.po...@microsoft.com> wrote: > > 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 <pkyzi...@alum.mit.edu> > Sent: Wednesday, April 18, 2018 11:43 AM > To: draft-ietf-tokbind-negotiation....@ietf.org > Cc: General Area Review Team <gen-art@ietf.org> > 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. > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
