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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Apr 2018 14:43:03 -0400

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.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 30 Apr 2018 22:00:54 +0000

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 <[email-masked]> 
Sent: Wednesday, April 18, 2018 11:43 AM
To: [email-masked]
Cc: General Area Review Team <[email-masked]>
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>.

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:

     ... it SHOULD

Section 4 states:

    ...

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.

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."

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.

---

From: John Bradley <[email-masked]>
Date: Mon, 30 Apr 2018 19:17:34 -0300

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 <[email-masked]> wrote:
> 
> Hi Paul,
> 
> Thanks for the feedback.
>