Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tokbind-negotiation-10

[Paul Kyzivat <[e-mail]>]

Andrei,

I've had my say. Do as you see fit.

	Thanks,
	Paul

On 11/26/17 5:18 PM, Andrei Popov wrote:
>> Otherwise it isn't much of a negotiation.
> I agree that this version negotiation mechanism is very basic; e.g., this is how TLS version negotiation (call it version indication?) works today.
> Various alternatives have been discussed several times, and WG consensus has been that we do not need more from our version negotiation mechanism.
> 
>> But this document doesn't apply to any version of TLS > 1.2, so that point is moot. What am I missing?
> This document is referenced by other documents that specify the use of TB with TLS > 1.2, so I think it does not hurt to clarify that EMS requirement applies to TLS <= 1.2.
> Before this language was added, WG participants commented that TLS >= 1.3 does not require EMS (because it's essentially implied in 1.3)...
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Sunday, November 26, 2017 1:49 PM
> To: Andrei Popov <[e-mail]>; [e-mail]
> Cc: General Area Review Team <[e-mail]>
> Subject: Re: Gen-ART Last Call review of draft-ietf-tokbind-negotiation-10
> 
> Andrei,
> 
> On 11/26/17 3:41 PM, Andrei Popov wrote:
>> Thanks for the review, Paul.
>>
>>> For example, if the supplied version is 3.5, what does it say about other versions supported?
>> 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.
>> Will expand this section to make things more clear in the next revision (after collecting more comments).
> 
> ISTM that for the client to simply indicate a single "max" version and for the server to then choose any lesser version that it supports implies that if you support 3.x then you must be able to support *any* 2.n or 1.n version. Otherwise it isn't much of a negotiation.
> 
> This isn't a problem if the policy is that anything added in a minor version update can be ignored if not understood. In that case if you support N.0 then you also can work with any N.M.
> 
> If that isn't the case, then it can still work if there is a policy that once a new major version is defined all the prior versions are frozen so that no new minor versions of them can be defined.
> 
>>> Please consider if these are saying what you mean, and tweak the wording.
>> This language is intended to make it clear that EMS is only required when using TLS <= 1.2. I would prefer to keep this language, perhaps removing the word "only".
> 
> But this document doesn't apply to any version of TLS > 1.2, so that point is moot. What am I missing?
> 
> 	Thanks,
> 	Paul
> 
>> Cheers,
>>
>> Andrei
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Sunday, November 26, 2017 12:06 PM
>> To: [e-mail]
>> Cc: General Area Review Team <[e-mail]>
>> Subject: Gen-ART Last Call review of draft-ietf-tokbind-negotiation-10
>>
>> 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%7C0f4698b009614092b71608d53509151a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636473235488200134&sdata=c0ASLsM1Y0evZrebBavBk%2FQDG5rVZUPxw57GpmAzih0%3D&reserved=0>.
>>
>> Document: draft-ietf-tokbind-negotiation-10
>> Reviewer: Paul Kyzivat
>> Review Date: 2017-11-26
>> IETF LC End Date: 2017-11-27
>> IESG Telechat date: TBD
>>
>> Summary:
>>
>> This draft is on the right track but has open issues, described in the review.
>>
>> Issues:
>>
>> Major: 0
>> Minor: 1
>> Nits:  1
>>
>> (1) MINOR:
>>
>> Section 2 states the following requirement:
>>
>>       ... it SHOULD
>>       indicate the latest (highest valued) version in
>>       TokenBindingParameters.token_binding_version.
>>
>> But this doesn'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.
>>
>> (2) NIT:
>>
>> The Introduction says:
>>
>>       The negotiation of the Token Binding protocol and key
>>       parameters in combination with TLS 1.3 and later versions is beyond
>>       the scope of this document.
>>
>> while item (3) of section 3 says:
>>
>>           This requirement only applies when TLS 1.2 or an older TLS
>>           version is used (see security considerations section below for
>>           more details).
>>
>> Taken together these seem odd - the requirement only applies to the entire scope of the document!
>>
>> Please consider if these are saying what you mean, and tweak the wording.
>>
>