Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

From: Leif Johansson <[email-masked]>
Date: Fri, 1 Jun 2018 16:32:34 +0200

On 2018-06-01 00:49, Brian Campbell wrote:
> I'd like to request some agenda time to cover the TTRP draft, which will
> likely consist of an overview and status update (with some gratuitous
> photos of recent IETF meeting locations) and a plea to move towards
> WGLC. Thanks!

In order to facilitate that... could we get some folks to review
the TTRP draft before 102?

Maybe... please... ??

	Cheers Leif

---

From: Brian Campbell <[email-masked]>
Date: Fri, 1 Jun 2018 10:06:32 -0600

It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-03

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Andrei Popov <[email-masked]>
Date: Fri, 1 Jun 2018 17:20:04 +0000

I’ll review,

Cheers,

Andrei

From: Unbearable <[email-masked]> On Behalf Of Brian Campbell
Sent: Friday, June 1, 2018 9:07 AM
To: Leif Johansson <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-03<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tokbind-ttrp-03&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cbe9b45e5942241330d0908d5c7d9bbd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636634660334123449&sdata=mfl4DReC846OoQSdyJvXQ0UjMYY9zeT8Hnp2jbXviis%3D&reserved=0>

On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <[email-masked]<mailto:[email-masked]>> wrote:

Maybe... please... ??

        Cheers Leif

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: "Manger, James" <[email-masked]>
Date: Tue, 5 Jun 2018 00:34:09 +0000

draft-ietf-tokbind-ttrp-03 looks ok.

There is nothing to distinguish between Token Binding being offered by the TTRP but not accepted by the client vs not being offered at all. I’m not sure if that matters. Perhaps it only makes sense for a server to look for these headers if it is sure all the reverse proxies that serve it support Token Binding and are configured to insert these headers.

Minor typos:
There is no example of Sec-Other-Token-Binding.

2.1.2 ABNF for EncodedTokenBindingType doesn’t strictly need "A" / "a" as “ABNF strings are case insensitive” [RFC5234 section 2.3<https://tools.ietf.org/html/rfc5234#section-2.3>] so just "A" would do. Having both does reinforce that upper and lower case can be used. Re-using the HEXDIG core ABNF rule would be slightly better, with a case-insensitive mention in the text.

   A Token Binding type value (a single byte) can be represented as an
   "EncodedTokenBindingType", which is a case-insensitive hex encoding.

     EncodedTokenBindingType = 1*2HEXDIG

                 Figure 2: Encoded Token Binding Type ABNF

Typo: section 3: “… they are *a* single logical server”

--
James Manger

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Saturday, 2 June 2018 2:07 AM
To: Leif Johansson <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

Maybe... please... ??

        Cheers Leif

---

From: Brian Campbell <[email-masked]>
Date: Tue, 5 Jun 2018 12:04:49 -0600

Thanks for the review, James. Replies to the individual comments are inline
below.

> draft-ietf-tokbind-ttrp-03 looks ok.

Thanks, that is high praise indeed!

There is nothing to distinguish between Token Binding being offered by the
> TTRP but not accepted by the client vs not being offered at all. I’m not
> sure if that matters. Perhaps it only makes sense for a server to look for
> these headers if it is sure all the reverse proxies that serve it support
> Token Binding and are configured to insert these headers.
>

Yeah, there is nothing provided to the back-end server to distinguish
between those two cases. But I can't think of a reason that the back-end
would do anything meaningful with that distinction.  The client and TTRP
are doing token binding or they are not and that is what gets conveyed
(along with the TB ID, of course).

> There is no example of Sec-Other-Token-Binding.

I was somewhat hesitant about adding support at all for conveying token
binding types other than provided and referred. That and a touch of
laziness led me to not do an example for Sec-Other-Token-Binding in the
last draft revision. But it is somewhat incomplete or inconsistent without
it. I'll add such an example in the next draft.

>
>
> 2.1.2 ABNF for EncodedTokenBindingType doesn’t strictly need "A" / "a" as
> “ABNF strings are case insensitive” [RFC5234 section 2.3
> <https://tools.ietf.org/html/rfc5234#section-2.3>] so just "A" would do.
> Having both does reinforce that upper and lower case can be used. Re-using
> the HEXDIG core ABNF rule would be slightly better, with a case-insensitive
> mention in the text.
>

I'd chosen not to reuse HEXDIG so as to allow upper and lower case.
However, I'd overlooked the case insensitive nature of ABNF strings you
referenced there. I think you're right that using the HEXDIG core ABNF rule
along with with a case-insensitive mention in the text is somewhat better.
I'll update accordingly.

>
> Typo: section 3: “… they are **a** single logical server”
>

Will fix.

Thanks!

>
> --
>
> James Manger
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Saturday, 2 June 2018 2:07 AM
> *To:* Leif Johansson <[email-masked]>
> *Cc:* IETF Tokbind WG <[email-masked]>
> *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for
> IETF 102
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Jun 2018 10:50:59 -0600

Thanks again for the review, James. I've submitted -04 with changes
addressing the comments.

Name:           draft-ietf-tokbind-ttrp
Revision:       04
Title:          HTTPS Token Binding with TLS Terminating Reverse Proxies
Document date:  2018-06-06
Group:          tokbind
Pages:          13
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tokbind-ttrp
-04.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-tt
rp
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-ttrp-04

On Tue, Jun 5, 2018 at 12:04 PM, Brian Campbell <[email-masked]>
wrote:

> Thanks for the review, James. Replies to the individual comments are
> inline below.
>
>
> On Mon, Jun 4, 2018 at 6:34 PM, Manger, James <
> [email-masked]> wrote:
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 6 Jun 2018 18:51:56 +0000

The document is well-written and clear, overall. I have a few editorial comments and some design comments:

  “Token Binding over HTTP [I-D.ietf-tokbind-https] provides a mechanism
   that enables HTTP servers to cryptographically bind cookies and other
   security tokens to a key held by the browser or other HTTP client,
   possession of which is proven on the TLS [RFC5246] connections over
   which the tokens are used.”

Editorial suggestion: “…to a key generated by the client.” Whether the browser, HTTP client, or underlying platform hold the TB key is implementation-specific and probably unnecessary detail here. Proof of possession is discussed in the next sentence.

  “The usage of the headers, both the reverse proxy adding _it_ and the
   application server using _them_ to bind cookies or other tokens, are to
   be configuration options of the respective systems as they will not
   always be applicable.”

Editorial: this sentence confuses me, esp. around “it” and “them”; perhaps it’s possible to simplify.

Section 2.2: Having three separate headers: Sec-Provided, Sec-Referred and Sec-Other catch-all would not be my design choice. I’d suggest either one header with a list of all TB IDs, or a separate header for each TB ID. Of course, if WG consensus exists on the current design, then that’s what it is.

   “Both "Sec-Provided-Token-Binding-ID" and "Sec-Referred-Token-Binding-
   ID" are single HTTP header field-valued…”

Somewhat related to the previous comment: this seems to be saying that there cannot be more than one referred TB ID, which is fine now, but not necessarily future proof.
TTRP seems to not be versioned; if, say, TB 2.0 uses multiple referred bindings per request, will we need TTRP 2.0 with all new headers?

It seems that TTRP needs to be either TB version-specific, i.e. explicitly say “this is for TB 1.0 only, and future TB versions will require new TTRP specs”, or be designed as a pipeline, passing whatever bindings the proxy was able to verify, possibly along with the negotiated TB protocol version.

Security and IANA considerations look good to me.

Cheers,

Andrei

Maybe... please... ??

        Cheers Leif

---

From: Brian Campbell <[email-masked]>
Date: Thu, 7 Jun 2018 13:08:52 -0600

Thanks for the review, Andrei.

I'll incorporate the editorial suggestions.

The design choice of having distinct Sec-Provided and Sec-Referred headers
was intentional and aimed at making the most common cases simple at the
application layer dealing with HTTP. The vast majority of the time there's
going to be only the Provided and a single header that carries that value
unadorned makes accessing that very straightforward.  Referred is the other
defined type with defined usage in HTTPSTB so TTRP has Sec-Referred for
that. Then there are 254 other undefined types and there was a request from
the WG (or a portion thereof) to allow for them somehow. A separate header
for every one of them seemed prohibitive to say the least. That's where the
Sec-Other catch-all comes from. There are trade-offs any design choice and
this is a bit of a hybrid but I feel it strikes a good balance of
simplicity for the common defined cases while still accommodating others.
Gauging WG consensus isn't particularity easy in this WG at this stage but
in my mind consensus is there. This would, of course, be a good time for
the WG to speak up to indicate otherwise, if that's not the case.

Nothing is future proof. TTRP is intended to facilitate deployments of
HTTPSTB. HTTPSTB isn't future proof or versioned and would need to change
to allow for more than one referred TB ID. Saying TTRP will work only with
a specific version may or may not prove true. And passing along the
negotiated TB protocol version may or may not accommodate future changes.
Future TB protocol versions may or may not even happen.

The single HTTP header field-valued text was largely put in there with the
hope/expectation that it would ease the registration process (after Jeff
suggested something similar for the Sec-Token-Binding header, IIRC). But
also because it was inline with the "exactly one" restriction in HTTPSTB.
But that text could easily be removed, I think.

On Wed, Jun 6, 2018 at 12:51 PM, Andrei Popov <
Andrei.Popov=[email-masked]> wrote:

> Editorial suggestion: “…to a key generated by the client.” Whether the
> browser, HTTP client, or underlying platform hold the TB key is
> implementation-specific and probably unnecessary detail here. Proof of
> possession is discussed in the next sentence.
>
>
>
>   “The usage of the headers, both the reverse proxy adding _*it*_ and the
>
>    application server using _*them*_ to bind cookies or other tokens, are
> to
>
> Section 2.2: Having three separate headers: Sec-Provided, Sec-Referred and
> Sec-Other catch-all would not be my design choice. I’d suggest either one
> header with a list of all TB IDs, or a separate header for each TB ID. Of
> course, if WG consensus exists on the current design, then that’s what it
> is.
>
>
>
> Somewhat related to the previous comment: this seems to be saying that
> there cannot be more than one referred TB ID, which is fine now, but not
> necessarily future proof.
>
> TTRP seems to not be versioned; if, say, TB 2.0 uses multiple referred
> bindings per request, will we need TTRP 2.0 with all new headers?
>
>
>
> It seems that TTRP needs to be either TB version-specific, i.e. explicitly
> say “this is for TB 1.0 only, and future TB versions will require new TTRP
> specs”, or be designed as a pipeline, passing whatever bindings the proxy
> was able to verify, possibly along with the negotiated TB protocol version.
>
>
>
> *From:* Unbearable <[email-masked]> *On Behalf Of *Brian
> Campbell
> *Sent:* Friday, June 1, 2018 9:07 AM
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tokbind-ttrp-03&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cbe9b45e5942241330d0908d5c7d9bbd2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636634660334123449&sdata=mfl4DReC846OoQSdyJvXQ0UjMYY9zeT8Hnp2jbXviis%3D&reserved=0>
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 7 Jun 2018 21:58:26 +0000

*   Gauging WG consensus isn't particularity easy in this WG at this stage but in my mind consensus is there.
Our awesome Chairs can probably help confirm one way or the other.

  *   Nothing is future proof.
  *   Saying TTRP will work only with a specific version may or may not prove true.
Sure. Just trying to understand what the thinking is: if TTRP is not supportable with TB X, we’ll just say “don’t use TTRP with TB X, use TTRPbis instead”?
And TTRPbis will probably define some new headers?

From: Brian Campbell <bcampbell=[email-masked]>
Sent: Thursday, June 7, 2018 12:09 PM
To: Andrei Popov <[email-masked]>
Cc: Leif Johansson <[email-masked]>; IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

The design choice of having distinct Sec-Provided and Sec-Referred headers was intentional and aimed at making the most common cases simple at the application layer dealing with HTTP. The vast majority of the time there's going to be only the Provided and a single header that carries that value unadorned makes accessing that very straightforward.  Referred is the other defined type with defined usage in HTTPSTB so TTRP has Sec-Referred for that. Then there are 254 other undefined types and there was a request from the WG (or a portion thereof) to allow for them somehow. A separate header for every one of them seemed prohibitive to say the least. That's where the Sec-Other catch-all comes from. There are trade-offs any design choice and this is a bit of a hybrid but I feel it strikes a good balance of simplicity for the common defined cases while still accommodating others. Gauging WG consensus isn't particularity easy in this WG at this stage but in my mind consensus is there. This would, of course, be a good time for the WG to speak up to indicate otherwise, if that's not the case.

Nothing is future proof. TTRP is intended to facilitate deployments of HTTPSTB. HTTPSTB isn't future proof or versioned and would need to change to allow for more than one referred TB ID. Saying TTRP will work only with a specific version may or may not prove true. And passing along the negotiated TB protocol version may or may not accommodate future changes. Future TB protocol versions may or may not even happen.

The single HTTP header field-valued text was largely put in there with the hope/expectation that it would ease the registration process (after Jeff suggested something similar for the Sec-Token-Binding header, IIRC). But also because it was inline with the "exactly one" restriction in HTTPSTB. But that text could easily be removed, I think.

On Wed, Jun 6, 2018 at 12:51 PM, Andrei Popov <Andrei.Popov=[email-masked]<mailto:Andrei.Popov=[email-masked]>> wrote:
The document is well-written and clear, overall. I have a few editorial comments and some design comments:

Cheers,

Andrei

From: Unbearable <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Campbell
Sent: Friday, June 1, 2018 9:07 AM
To: Leif Johansson <[email-masked]<mailto:[email-masked]>>
Cc: IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

Maybe... please... ??

        Cheers Leif

---

From: Brian Campbell <[email-masked]>
Date: Thu, 7 Jun 2018 16:22:39 -0600

Yeah, that's pretty much the thinking. Hopefully, TTRP is supportable with
TB X. Or the drivers for TB X can be accommodated in a way that continue to
work with TTRP unchanged. But if not, TTRPnext will be the new way with the
new TB X. And that likely will mean some new headers.

On Thu, Jun 7, 2018 at 3:58 PM, Andrei Popov <
Andrei.Popov=[email-masked]> wrote:

>
>    - Gauging WG consensus isn't particularity easy in this WG at this
>    stage but in my mind consensus is there.
>
>    - Nothing is future proof.
>    - Saying TTRP will work only with a specific version may or may not
>    prove true.
>
> Sure. Just trying to understand what the thinking is: if TTRP is not
> supportable with TB X, we’ll just say “don’t use TTRP with TB X, use
> TTRPbis instead”?
>
> *From:* Brian Campbell <bcampbell=[email-masked]>
> *Sent:* Thursday, June 7, 2018 12:09 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Leif Johansson <[email-masked]>; IETF Tokbind WG <[email-masked]>
>