[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.
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Eric Rescorla
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Andrei Popov
- Re: [Unbearable] Ben Campbell's Discuss on draft-… John Bradley
- Re: [Unbearable] Ben Campbell's Discuss on draft-… John Bradley
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Ben Campbell
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Andrei Popov
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Ben Campbell
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Eric Rescorla
- [Unbearable] Ben Campbell's Discuss on draft-ietf… Ben Campbell
- Re: [Unbearable] Ben Campbell's Discuss on draft-… Dirk Balfanz