[Unbearable] Opsdir last call review of draft-ietf-tokbind-https-14

Tim Chown <tim.chown@jisc.ac.uk> Tue, 08 May 2018 22:53 UTC

Return-Path: <tim.chown@jisc.ac.uk>
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 B407212EB19; Tue, 8 May 2018 15:53:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tim Chown <tim.chown@jisc.ac.uk>
To: <ops-dir@ietf.org>
Cc: unbearable@ietf.org, draft-ietf-tokbind-https.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152581999870.2396.2436476098436671278@ietfa.amsl.com>
Date: Tue, 08 May 2018 15:53:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/9xilvTaawHi8lLeUfC9Ci35Ff9M>
Subject: [Unbearable] Opsdir last call review of draft-ietf-tokbind-https-14
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: Tue, 08 May 2018 22:53:19 -0000

Reviewer: Tim Chown
Review result: Ready

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document describes a set of mechanisms that allow HTTP servers to
cryptographically bind security tokens such as cookies and OAuth tokens to TLS
connections for both first-party and federated scenarios, the latter being
cases where the tokens are bound to a TLS connection the client has with a
server other than the one issuing the token.

The document is well structured and written.

It is Ready for publication, with minor nits.

Minor comments/nits:

Some prior knowledge is assumed, and some terms not expanded on first use, but
there is no terminology section.

It may be useful to include a diagram of the relationship between the various
elements in a federated scenario; I found myself drawing this while reading the
document the first time through.

In the diagram in Section 5.1, is that a different signature associated with
TBID1 and TBID2, if so perhaps label as signature1 and signature2?

There is some mixture of 'should' and 'SHOULD' through the document, likewise
'must' and 'MUST'; is this intentional?  In some cases, lower case seems OK,
but in others, it's not so clear, e.g., the last bullet point of Section 7
would seem to be a SHOULD not a should?