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

From: Dirk Balfanz <[email-masked]>
Date: Mon, 4 Jun 2018 13:26:51 -0700

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 <[email-masked]> 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.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 Jun 2018 16:30:08 -0700

Ben,

Does the following new text address your concern:
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii&url=https://raw.githubusercontent.com/TokenBinding/Internet-Drafts/master/draft-ietf-tokbind-https-18.xml

On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <
balfanz=[email-masked]> wrote:

>> After reading section 6 several times, I don't know what it means. I
>> think it's [...]
>>
>
> Addressed in new draft.
>
>
>>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 26 Jun 2018 13:41:09 -0500

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 <[email-masked]> wrote:
> 
> Ben,
> 
> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=[email-masked]> 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.
> 
> After reading section 6 several times, I don't know what it means. I think it's [...]
> 
> Addressed in new draft.
> 
> 
> §1.1: Please consider using the boilerplate from 8174 across the cluster. Both
> - 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
> Yes, we did discuss it. This was chosen consciously to be in sync with cookies and their expirations / manual user-initiated purges.
> 
> - Why
> - 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"
> - example: Am I correct to assume the backslashes are just for print purposes
> - first paragraph, "Within the latter context...": There was no former context.
> §7.1 and §7.2: These sections seem to be copied from (or restate requirements

---

From: Andrei Popov <[email-masked]>
Date: Tue, 26 Jun 2018 18:54:47 +0000

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).

Cheers,

Andrei

-----Original Message-----
From: Ben Campbell <[email-masked]> 
Sent: Tuesday, June 26, 2018 11:41 AM
To: Eric Rescorla <[email-masked]>
Cc: Dirk Balfanz <balfanz=[email-masked]>; [email-masked]; Tokbind WG <[email-masked]>; The IESG <[email-masked]>; John Bradley <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)

Thanks!

Ben.

> 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
> 
> 
> 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
> §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:
> 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?
> 
> [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.
> 
> 
> purposes and are not in the actual message? If so, please mention that.
> 
> Addressed in new draft.
> 
> 
> § 2.1:
> - 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.
> 
> 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.
> 
> 
> in) the protocol and negotiation drafts. Can they be included by 
> reference instead, or at least attributed?
> 
> Addressed in new draft.
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 26 Jun 2018 13:58:20 -0500

> On Jun 26, 2018, at 1:54 PM, Andrei Popov <[email-masked]> wrote:
> 
> Hi Ben,
> 
> Thanks for the review.
> 

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.

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2018 17:12:46 -0400

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 <[email-masked]> wrote:

> >> 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 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
> >
> > Cc: Dirk Balfanz <balfanz=[email-masked]>;
> [email-masked]; Tokbind WG <[email-masked]>; The
> IESG <[email-masked]>; John Bradley <[email-masked]>;
> [email-masked]
> > Subject: Re: [Unbearable] Ben Campbell's Discuss on
> draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
> >
> > 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.)
> >

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jun 2018 17:14:28 -0400

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 <[email-masked]> wrote:

>> >> 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
>> > 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.)
>> >

---

From: Andrei Popov <[email-masked]>
Date: Tue, 26 Jun 2018 21:19:34 +0000

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

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

John B.
On Tue, Jun 26, 2018, 5:12 PM John Bradley <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

> On Jun 26, 2018, at 1:54 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Ben,
>
> Thanks for the review.
>

Thanks!

Ben.

> From: Ben Campbell <[email-masked]<mailto:[email-masked]>>
> To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
> Cc: Dirk Balfanz <balfanz=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tokbind WG <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; John Bradley <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Ben,
>>
>> 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>
>> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
>> 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>
>> 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>
>>
>>
>>
>> [email-masked]<mailto:[email-masked]>
>> 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>
>>
>>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Jun 2018 14:25:06 -0700

Should be, I need to do a double check to make sure other comments were
dealt with, but assuming so, then yes. Should be able to do this tomorrow

-Ekr

On Tue, Jun 26, 2018 at 2:19 PM, Andrei Popov <[email-masked]>
wrote:

> *From:* John Bradley <[email-masked]>
> *Sent:* Tuesday, June 26, 2018 2:14 PM
> *To:* Ben Campbell <[email-masked]>
> *Cc:* Andrei Popov <[email-masked]>; Eric Rescorla <
> [email-masked]>; Dirk Balfanz <balfanz=[email-masked]>;
> [email-masked]; Tokbind WG <[email-masked]>; IESG
> <[email-masked]>; [email-masked]
>
> *Subject:* Re: [Unbearable] Ben Campbell's Discuss on
> paragraph 2?
> <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>
> <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>
> 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.
> >>
> <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>
> <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>
> >>
> >>
> >>
> <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>
> >>
> >>
> >
>
>