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

[Andrei Popov <[e-mail]>]

Done: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/.

From: John Bradley <[e-mail]>
Sent: Tuesday, June 26, 2018 2:14 PM
To: Ben Campbell <[e-mail]>
Cc: Andrei Popov <[e-mail]>; Eric Rescorla <[e-mail]>; Dirk Balfanz <balfanz=[e-mail]>; [e-mail]; Tokbind WG <[e-mail]>; IESG <[e-mail]>; [e-mail]
Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)

PS I suppose we need DIRK OR Andre to push a version with the changes.

John B.
On Tue, Jun 26, 2018, 5:12 PM John Bradley <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Ben.

EKR once this Discuss is cleared are we good to move on to the final embrace of the RFC editor?

Regards
John B.

On Tue, Jun 26, 2018, 2:58 PM Ben Campbell <[e-mail]<mailto:[e-mail]>> wrote:


> On Jun 26, 2018, at 1:54 PM, Andrei Popov <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
> Sent: Tuesday, June 26, 2018 11:41 AM
> To: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
> Cc: Dirk Balfanz <balfanz=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Tokbind WG <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; John Bradley <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> 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 <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Ben,
>>
>> Does the following new text address your concern:
>> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/a<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxml2rfc.tools.ietf.org%2Fcgi-bin%2Fxml2rfc.cgi%3FmodeAsFormat%3Dhtml%2Fa&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842164263&sdata=Y%2BREp5UE5Jm9yUeshFJ1eXblnfs0C5W31uG%2Fk6mtIO0%3D&reserved=0>
>> scii&url=https://raw.githubusercontent.com/TokenBinding/Internet-Draft<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2FTokenBinding%2FInternet-Draft&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842174271&sdata=Lg7YBDv2yEZP3pYMkztxew9u34xhtNnY8ocvLuujD8M%3D&reserved=0>
>> s/master/draft-ietf-tokbind-https-18.xml
>>
>>
>> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=[e-mail]<mailto:[e-mail]>> 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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tokbind-https-16&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842184279&sdata=IJHYDJSWoUy5Ao8EWj1lHn8s5WuqTCD%2FH5hAVbmMdVk%3D&reserved=0>). See below (inline) for details.
>>
>> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <[e-mail]<mailto:[e-mail]>> 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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842184279&sdata=irsD0beoR1vbnMm%2FB5vrDF4gwAs4HHulXEumzjFJj0M%3D&reserved=0>
>> 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/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tokbind-https%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842194288&sdata=m3aq2LeWis4PZmysUZeVb%2Fai%2BqEaewg%2BAlv8BB68%2FxM%3D&reserved=0>
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/unbearable<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cf57a905ae88e4850fb8808d5dba9d524%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636656444842194288&sdata=NLYzqLIc9d9qH0VTbDcC%2BYdYaSR%2Bs653eBpQ6Alk%2FbA%3D&reserved=0>
>>
>>
>