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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 November 2017 15:15 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73D412711D; Mon, 27 Nov 2017 07:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3i1ivpSaRfn; Mon, 27 Nov 2017 07:15:23 -0800 (PST)
Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id A59EF128796; Mon, 27 Nov 2017 07:15:23 -0800 (PST)
X-AuditID: 12074412-1e5ff7000000748d-45-5a1c2c0a58b4
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 93.6E.29837.A0C2C1A5; Mon, 27 Nov 2017 10:15:22 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vARFFLCc018971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Nov 2017 10:15:22 -0500
To: Andrei Popov <Andrei.Popov@microsoft.com>, "draft-ietf-tokbind-negotiation.all@ietf.org" <draft-ietf-tokbind-negotiation.all@ietf.org>
Cc: General Area Review Team <gen-art@ietf.org>
References: <c863ce3f-149b-8d97-592b-6ce6dbc62660@alum.mit.edu> <MWHPR21MB01897C017B48452218F353F88C240@MWHPR21MB0189.namprd21.prod.outlook.com> <c604191d-0fa2-3865-4922-4202c3d36bc8@alum.mit.edu> <MWHPR21MB0189D9A14FDD8F265F27A7B48C240@MWHPR21MB0189.namprd21.prod.outlook.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <8eff7718-c100-14be-147b-ffed763e99ab@alum.mit.edu>
Date: Mon, 27 Nov 2017 10:15:21 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <MWHPR21MB0189D9A14FDD8F265F27A7B48C240@MWHPR21MB0189.namprd21.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixO6iqMulIxNlsGObosWPSTOYLXa0/GWx uPrqM4sDs8eSJT+ZPFp3/GUPYIrisklJzcksSy3St0vgymjfuIml4KxuxfOdT5gaGN+qdDFy ckgImEgsOL6ErYuRi0NIYAeTxNYTS5lBEkICD5kk9t0zA7GFBbwkjtw8xgJSJCIwlVFiyuSF rCAJZgF9ib9PFjNBdM9mknjZdBWsm01AS2LOof9AHRwcvAL2Eqvv6IKEWQRUJdqP7WACsUUF 0iTuzHgIZvMKCEqcnPmEBcTmFIiVOPN7MjPEfDOJeZsfQtniEreezGeCsOUlmrfOZp7AKDAL SfssJC2zkLTMQtKygJFlFaNcYk5prm5uYmZOcWqybnFyYl5eapGumV5uZoleakrpJkZIMAvt YFx/Uu4QowAHoxIPr4KPdJQQa2JZcWXuIUZJDiYlUd4F2VJRQnxJ+SmVGYnFGfFFpTmpxYcY JTiYlUR4ZR8ClfOmJFZWpRblw6SkOViUxHl/Llb3ExJITyxJzU5NLUgtgsnKcHAoSfCGa8tE CQkWpaanVqRl5pQgpJk4OEGG8wANX6sFVMNbXJCYW5yZDpE/xWjJ0dNz4w8Tx46bd4Hks5mv G5iFWPLy81KlxHnzQBoEQBoySvPgZsKS0ytGcaAXhXnXgazmASY2uKmvgBYyAS28uR/km+KS RISUVAPjvFbRf4bhqYKaUaZvFBazlJu+n/e8QPr04vBVLUoTg/V+nTh8zz31s72g1C0GO33H RWvK7337LPP09ifjTun0PQu1trFElcb3rtiTvC5ui+9S5+emGR3qx+/b/FPkuBf7K+2Hkob3 kZMu5+4efpU3q3zXwYN6U9/NfjJretOt7TUhYvEnMh31lFiKMxINtZiLihMB7CKpgikDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/29-iVv0xwQ5fdHAiSFFlKDa7hv0>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tokbind-negotiation-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Nov 2017 15:15:30 -0000

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:pkyzivat@alum.mit.edu]
> Sent: Sunday, November 26, 2017 1:49 PM
> To: Andrei Popov <Andrei.Popov@microsoft.com>;; draft-ietf-tokbind-negotiation.all@ietf.org
> Cc: General Area Review Team <gen-art@ietf.org>;
> 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:pkyzivat@alum.mit.edu]
>> Sent: Sunday, November 26, 2017 12:06 PM
>> To: draft-ietf-tokbind-negotiation.all@ietf.org
>> Cc: General Area Review Team <gen-art@ietf.org>;
>> 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.
>>
>