[Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)

Ben Campbell <ben@nostrum.com> Wed, 09 May 2018 20:38 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 C002F128954; Wed, 9 May 2018 13:38:50 -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-https@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: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com>
Date: Wed, 09 May 2018 13:38:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/hMTKEYumcFrrTdpKGnM_QRWvLqo>
Subject: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and 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:38:51 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-tokbind-https-14: Discuss

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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I plan to ballot "YES", but I want to clear up once concern first:

After reading section 6 several times, I don't know what it means. I think it's
hard enough to understand that implementers will not interpret it in a
consistent way. It's entirely possibly this is "just me", but I want to discuss
it before progressing. I think this can be fixed easily with either some
clarification text, or an argument that the issue is, in fact, "just me".

In particular, the 2nd paragraph is pretty convoluted, but even after several
readings the best I can get out of it is "Servers that use token-binding with
native clients should let them use token-binding", which I suspect is not the
(entire) point.  Since these "native applications" are described as using HTTP,
it's not obvious to me what is different for them. Additionally, I assumed
"native applications"  to mean non-browser, yet the third paragraph talks about
"such implementations" but uses a browser-based example. Is there a different
meaning intended?


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

Substantive Comments:

§1.1: Please consider using the boilerplate from 8174 across the cluster. Both
this and the protocol draft have lower case keyword instances.

§8.2:
- Does it really make sense to wait for a user to request the keys be expired?
I suspect the average user does this about never. Did the working group discuss
possibly making the keys default to expiring after some period of time? - Why
is the SHOULD in paragraph 2 not a MUST?

Editorial Comments:

§2:
- Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in [RFC7230]
style, see also Section 8.3 of [RFC7231]):" The open parenthesis before "in"
seems misplaced. Also, as written the comma after "style" creates a comma
splice. (Note that this pattern occurs elsewhere in the document.)

- Paragraph 3: The paragraph is a single hard-to-parse sentence. Please
consider breaking into simpler sentences.

- example: Am I correct to assume the backslashes are just for print purposes
and are not in the actual message? If so, please mention that.

§ 2.1:
- first paragraph, "Within the latter context...": There was no former context.
I suggest "Within that context..." - 2nd paragraph: The first sentence is hard
to parse. I suggest breaking it into separate paragraphs, or restructure
without the center-imbedding. - 2nd to last paragraph: Does "SHOULD generally"
mean the same as just "SHOULD"?

§5.1: 2nd paragraph: Unneeded comma in "... itself, to another server..."

§5.2,
- last bullet: " (between client and Token Consumer)" seems more than
parenthetical. Please consider removing the parentheses. - paragraph after last
bullet: The parenthetical phrase starting with "(proving possession...) is
quite long and makes the sentence hard to parse. Given that the concept is
covered in the immediately preceding paragraph, can it be removed?

§7.1 and §7.2: These sections seem to be copied from (or restate requirements
in) the protocol and negotiation drafts. Can they be included by reference
instead, or at least attributed?

§7.2, 2nd paragraph: This seams like a restatement of §7.1.

§8.3: Unneeded comma in first sentence.