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

Ben Campbell <ben@nostrum.com> Wed, 09 May 2018 19:55 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 CC834127909; Wed, 9 May 2018 12:55:11 -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-protocol@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: <152589571183.4023.6683971544993897004.idtracker@ietfa.amsl.com>
Date: Wed, 09 May 2018 12:55:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/8wsnOcBC07ELLtkhZ481GJlqFlA>
Subject: [Unbearable] Ben Campbell's Yes on draft-ietf-tokbind-protocol-17: (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 19:55:12 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-tokbind-protocol-17: 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-protocol/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document. I am balloting "yes", but I have a few minor comments:

Minor Comments:

§1.1: Please consider using the boilerplate from 8174 across this cluster.
There are a few instances of lower case keywords across the set.

§3.1: This section does not seem to sufficiently define the difference between
provided_token_binding and referred_token_binding, other than as a mention of
the use case from the HTTPS doc. It would be nice if other application protocol
bindings did not have to refer to the HTTPS doc to fully understand the basic
protocol. (Or is it assumed that only HTTPS will use referred_token_binding)?

§3.2, last paragraph: Why is this a SHOULD? Do you envision scenarios where it
would make sense to behave differently? For example, if an application made
Token Binding IDs available as structured data, what would be the consequences?

§3.3, last bullet: Is the EKM from the TLS connection at the time the binding
is established (rather than when it might later be used)?

§4.1, 2nd paragraph: Why only a SHOULD? It seems like intentionally storing
keys in an insecure manner makes the entire protocol pointless.

§6.1 (and others): I'm not sure what it means for the expert to be "advised to
encourage". Is there something more concrete that could be said? Does this give
the advisor grounds to reject a registration?

Editorial Comments:

§1: Please expand TPM on first mention.