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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 26 November 2017 21:49 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 1B89D12704B; Sun, 26 Nov 2017 13:49:34 -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 TEWkfh8onA7c; Sun, 26 Nov 2017 13:49:29 -0800 (PST)
Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id A6F65126FB3; Sun, 26 Nov 2017 13:49:29 -0800 (PST)
X-AuditID: 12074411-f95ff70000007f0a-0f-5a1b36e89179
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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 59.D3.32522.8E63B1A5; Sun, 26 Nov 2017 16:49:28 -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 vAQLnQPj004723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Nov 2017 16:49:28 -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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <c604191d-0fa2-3865-4922-4202c3d36bc8@alum.mit.edu>
Date: Sun, 26 Nov 2017 16:49:26 -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: <MWHPR21MB01897C017B48452218F353F88C240@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+NgFprBKsWRmVeSWpSXmKPExsUixO6iqPvCTDrK4MBCa4sfk2YwW+xo+cti cfXVZxYHZo8lS34yebTu+MsewBTFZZOSmpNZllqkb5fAlbHx12TmgqXKFTOWL2JqYJwr08XI ySEhYCJxrPceUxcjF4eQwA4miSkr9zNCOA+ZJDYuv8IKUiUs4CVx5OYxFpCEiMBURokpkxeC JZgF9CX+PlkM1T6JUeLfpZ1gCTYBLYk5h/6zgNi8AvYSz6dPYQKxWQRUJb4+vMoIYosKpEnc mfGQCaJGUOLkzCdg9ZwCsRKd23eyQCwwk5i3+SEzhC0ucevJfCYIW16ieets5gmMArOQtM9C 0jILScssJC0LGFlWMcol5pTm6uYmZuYUpybrFicn5uWlFuma6uVmluilppRuYoQEtOAOxhkn 5Q4xCnAwKvHw7jgiGSXEmlhWXJl7iFGSg0lJlHdBtlSUEF9SfkplRmJxRnxRaU5q8SFGCQ5m JRFegXKgHG9KYmVValE+TEqag0VJnJdvibqfkEB6YklqdmpqQWoRTFaGg0NJgneeqXSUkGBR anpqRVpmTglCmomDE2Q4D9DwzSA1vMUFibnFmekQ+VOMlhw9PTf+MHHsuHkXSD6b+bqBWYgl Lz8vVUqcNxOkQQCkIaM0D24mLEG9YhQHelGYdxFIFQ8wucFNfQW0kAlo4dOT4iALSxIRUlIN jHbhtwNvM9p9WzmxjvVFoVGbxNtQGdmER34/bv64H3OhZdvvpqAlkRH1Fh9kTUwUvjN/msgx /eEvTkXbowZ7dbif3DGPtpa3LWm7Ypj/9va23PTTBxr6d7G0tYY9VdvdM9/36YFpCaFPni7Z LmG34PWpTcsWRgp0zf+3qe3UBK/PT3a9/TSz8YoSS3FGoqEWc1FxIgC1aW+xKwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/pcfXznGJtHx6QYPa34RXZcAQRII>
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: Sun, 26 Nov 2017 21:49:34 -0000

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