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

Ben Campbell <ben@nostrum.com> Tue, 26 June 2018 18:58 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2451310FF; Tue, 26 Jun 2018 11:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JzoaN8dHsWc; Tue, 26 Jun 2018 11:58:26 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E55D13112A; Tue, 26 Jun 2018 11:58:26 -0700 (PDT)
Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5QIwLKV085852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jun 2018 13:58:22 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <097D19CC-EAB7-4F9F-98C4-B4030B838464@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_8123AB76-087C-486C-A9F5-CD243AE1B04C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 26 Jun 2018 13:58:20 -0500
In-Reply-To: <CY4PR21MB0774D87B730D6A726AA272568C490@CY4PR21MB0774.namprd21.prod.outlook.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org>, "draft-ietf-tokbind-https@ietf.org" <draft-ietf-tokbind-https@ietf.org>, Tokbind WG <unbearable@ietf.org>, The IESG <iesg@ietf.org>, John Bradley <ve7jtb@ve7jtb.com>, "tokbind-chairs@ietf.org" <tokbind-chairs@ietf.org>
To: Andrei Popov <Andrei.Popov@microsoft.com>
References: <152589833077.4037.7403393365772291429.idtracker@ietfa.amsl.com> <CADHfa2Aj9_-X-rtPR7OU-_cEXC=MnHpv88O_HTmB0-Yd-X_LLA@mail.gmail.com> <CABcZeBOb9G3jTnOg6ucba2060EqObM8LEo9F16mCCvwdHaU9=A@mail.gmail.com> <94E6261D-7920-4C65-BDB3-A0B3144323C5@nostrum.com> <CY4PR21MB0774D87B730D6A726AA272568C490@CY4PR21MB0774.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/YQHRSLlLfRROVN3EJFqu-P6qc5U>
Subject: Re: [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.26
Precedence: list
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, 26 Jun 2018 18:58:32 -0000


> On Jun 26, 2018, at 1:54 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> 
> Hi Ben,
> 
> Thanks for the review.
> 
>> Are the “applications” from paragraph 3 the same as those from paragraph 2?
> 
> Yes, the same throughout paragraphs 1, 2 and 3.
> 
>> It seems like paragraph 2 is talking more about local APIs (at least, I see that was mentioned in the text in version 17 but not in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in control may be weak enough for web applications that the distinction does not matter.)
> 
> The APIs provided by the TB implementation and called by the application are local APIs.
> The application needs to make a decision whether to request that the TB implementation include a Referred binding in the TB message or not.
> In the example, the server provides a signal to the application using the Include-Referred-Token-Binding-ID HTTP response header.
> The signal could be different, or an application may have out-of-band ways to determine this (e.g. a local database of RP->IDP associations).

I just re-read the 3rd paragraph, and I think I missed the “then” in “which then signals” on the first reading. It’s fine as is.

Thanks!

Ben.

> 
> Cheers,
> 
> Andrei
> 
> -----Original Message-----
> From: Ben Campbell <ben@nostrum.com>
> Sent: Tuesday, June 26, 2018 11:41 AM
> To: Eric Rescorla <ekr@rtfm.com>
> Cc: Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org>rg>; draft-ietf-tokbind-https@ietf.org; Tokbind WG <unbearable@ietf.org>rg>; The IESG <iesg@ietf.org>rg>; John Bradley <ve7jtb@ve7jtb.com>om>; tokbind-chairs@ietf.org
> Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
> 
> Hi, thanks for the pointer.
> 
> The text in version 18 is sufficient to clear my discuss. I have one remaining (or maybe new) non-blocking question for section 6:
> 
> Are the “applications” from paragraph 3 the same as those from paragraph 2? It seems like paragraph 2 is talking more about local APIs (at least, I see that was mentioned in the text in version 17 but not in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in control may be weak enough for web applications that the distinction does not matter.)
> 
> I did not check my editorial comments.
> 
> Thanks!
> 
> Ben.
> 
>> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> 
>> Ben,
>> 
>> Does the following new text address your concern:
>> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/a
>> scii&url=https://raw.githubusercontent.com/TokenBinding/Internet-Draft
>> s/master/draft-ietf-tokbind-https-18.xml
>> 
>> 
>> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=40google..com@dmarc.ietf.org> wrote:
>> Hi Ben,
>> 
>> thanks for the feedback. Most of it is addressed in the new draft (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below (inline) for details.
>> 
>> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostrum.com> wrote:
>> 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 [...]
>> 
>> Addressed in new draft.
>> 
>> 
>> ----------------------------------------------------------------------
>> 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.
>> 
>> Addressed in new draft.
>> 
>> 
>> §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?
>> 
>> Yes, we did discuss it. This was chosen consciously to be in sync with cookies and their expirations / manual user-initiated purges.
>> 
>> - Why
>> is the SHOULD in paragraph 2 not a MUST?
>> 
>> Addressed in new draft.
>> 
>> 
>> 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.
>> 
>> Addressed in new draft.
>> 
>> 
>> - 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.
>> 
>> Addressed in new draft.
>> 
>> 
>> § 2.1:
>> - first paragraph, "Within the latter context...": There was no former context.
>> I suggest "Within that context..."
>> 
>> Addressed in new draft.
>> 
>> - 2nd paragraph: The first sentence is hard to parse. I suggest
>> breaking it into separate paragraphs, or restructure without the
>> center-imbedding.
>> 
>> Addressed in new draft.
>> 
>> - 2nd to last paragraph: Does "SHOULD generally"
>> mean the same as just "SHOULD"?
>> 
>> Addressed in new draft.
>> 
>> 
>> §5.1: 2nd paragraph: Unneeded comma in "... itself, to another server..."
>> 
>> Addressed in new draft.
>> 
>> 
>> §5.2,
>> - last bullet: " (between client and Token Consumer)" seems more than
>> parenthetical. Please consider removing the parentheses.
>> 
>> Addressed in new draft.
>> 
>> - 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?
>> 
>> Addressed in new draft.
>> 
>> 
>> §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?
>> 
>> Addressed in new draft.
>> 
>> 
>> §7.2, 2nd paragraph: This seams like a restatement of §7.1.
>> 
>> Addressed in new draft.
>> 
>> 
>> §8.3: Unneeded comma in first sentence.
>> 
>> Addressed in new draft.
>> 
>> Thanks again for the thoughtful comments!
>> 
>> Dirk.
>> 
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>> 
>> 
>