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

Ben Campbell <ben@nostrum.com> Wed, 09 May 2018 20:05 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: unbearable@ietf.org
Delivered-To: unbearable@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B93127863; Wed, 9 May 2018 13:05:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-tokbind-negotiation@ietf.org, John Bradley <ve7jtb@ve7jtb.com>, tokbind-chairs@ietf.org, ve7jtb@ve7jtb.com, unbearable@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152589634849.4060.1233669853296271255.idtracker@ietfa.amsl.com>
Date: Wed, 09 May 2018 13:05:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/Wo8LhuZlwLvwUMa1JNZmD7Sh2e0>
Subject: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-negotiation-12: (with COMMENT)
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 09 May 2018 20:05:48 -0000

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/



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