Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)

Ben Campbell <ben@nostrum.com> Thu, 10 May 2018 22:26 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29AE12EBA5; Thu, 10 May 2018 15:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 vZ8bA8aehjen; Thu, 10 May 2018 15:26:21 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C5912EB97; Thu, 10 May 2018 15:26:20 -0700 (PDT)
Received: from [10.0.1.94] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4AMQJWR059608 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 May 2018 17:26:20 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.94]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <72871FC9-7CEF-4749-96A3-3CD46E8A6F6F@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CAFBE3F8-7D2D-4076-B55B-A7022AAFFDAD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Thu, 10 May 2018 17:26:18 -0500
In-Reply-To: <DM5PR21MB0507D89084BCFF1A8BCC19C48C990@DM5PR21MB0507.namprd21.prod.outlook.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-tokbind-negotiation@ietf.org" <draft-ietf-tokbind-negotiation@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>, "unbearable@ietf.org" <unbearable@ietf.org>
To: Andrei Popov <Andrei.Popov@microsoft.com>
References: <152589634849.4060.1233669853296271255.idtracker@ietfa.amsl.com> <DM5PR21MB0507D89084BCFF1A8BCC19C48C990@DM5PR21MB0507.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/K8lzI5nheDh6LzuUeBdAkwNKNuw>
Subject: Re: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 22:26:28 -0000


> On May 9, 2018, at 4:50 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> 
> Hi Ben,
> 
> Thanks for the review; some answers below.
>> Additionally, do I understand the version negotiation to require the client to support all previous version from the one it initially advertises?
> No, the draft says specifically:
> " 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.”
> 

We have a separate thread on this point now, so I will respond there.


>> §1.1: Please consider using the 8174 boilerplate across the cluster. While I did not find lower case keywords in this draft, I did in the other two and it would be best to be consistent across all three.
> Will make this change in the next revision.

Thanks!

> 
>> §2: "[I-D.ietf-tokbind-protocol] describes version {1, 0} of the protocol.":
>> While one might infer that version to be {1,0} give the name "Token Binding 1.0", I never saw it explicitly mentioned.
> Sorry, I did not understand the concern. Can you elaborate?

Ths probably should have been a comment on the protocol draft, not the negotiation draft. That is, the protocol draft never explicitly claims to be {1,0}. But it’s not a big deal because I think most implementers would infer that from the title “Token Binding 1.0"

> 
> Thanks,
> 
> Andrei
> 
> -----Original Message-----
> From: Ben Campbell <ben@nostrum.com>
> Sent: Wednesday, May 9, 2018 1:06 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-tokbind-negotiation@ietf.org; John Bradley <ve7jtb@ve7jtb.com>om>; tokbind-chairs@ietf.org; ve7jtb@ve7jtb.com; unbearable@ietf.org
> Subject: Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-tokbind-negotiation-12: Yes
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C3a1591db5ceb4c9f9e3508d5b5e842b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636614931539696277&sdata=tz5MtEsJwqlG7QHQWgLVy6HMgX1xyLTqzmnFA7U9Gmc%3D&reserved=0
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-negotiation%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C3a1591db5ceb4c9f9e3508d5b5e842b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636614931539696277&sdata=JMexEpyWjrBwY5V2PvFVHCqaXtPlw7PaBRJK4Qk%2F5lc%3D&reserved=0
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this document. I am balloting "yes", but have a few comments:
> 
> - I support Alexey's DISCUSS. Additionally, do I understand the version negotiation to require the client to support all previous version from the one it initially advertises? If so, how would you deprecate a version at some time in the future?
> 
> - I shared some of the confusion about this being limited to TLS 1.2 and earlier. In particular, there is repeating language that to the effect of "For TLS 1.2 and earlier...", which seems strange for a draft that only supports 1.2 in the first place.
> 
> §1.1: Please consider using the 8174 boilerplate across the cluster. While I did not find lower case keywords in this draft, I did in the other two and it would be best to be consistent across all three.
> 
> §2: "[I-D.ietf-tokbind-protocol] describes version {1, 0} of the protocol.":
> While one might infer that version to be {1,0} give the name "Token Binding 1.0", I never saw it explicitly mentioned.
> 
> Editorial Comments:
> 
> §2: "Please note that the server MAY select any lower protocol version, see Section 3": comma splice
> 
>