Subject: [Unbearable] HTTPSTB: discuss scoping of token binding keys earlier in the document

From: Brian Campbell <[email-masked]>
Date: Fri, 13 May 2016 15:15:02 -0600

I put in https://github.com/TokenBinding/Internet-Drafts/issues/33 but am
sending this message to the list too as some/many WG participants don't
actively monitor GitHub (as suggested by Andrei). Text of the issue is
copied below. Thanks!

As of draft-ietf-tokbind-https-03 in the Privacy Considerations Section 5.1
Scoping of Token Binding Keys
<https://tools.ietf.org/html/draft-ietf-tokbind-https-03#section-5.1>is the
first real mention that token binding keys/ids should be scoped to public
suffix + 1. Though the first sentence in 3.1 hints at it, it's not defined
until later.

The scope of where TB keys are sent is a pretty fundamental part of HTTPSTB
and, as such, I believe should be defined/discussed in Section 2 along with
the Sec-Token-Binding header that the scoping applies to. The Privacy
Considerations are still good considerations but then could refer back to
the scoping definition in Sec 2 rather than being the definition.

Public suffix + 1 makes sense as the scope for browser user agents but is
maybe overly restrictive/prescriptive for some other HTTPS cases. OAuth
access tokens come to mind, although it's still up in the air at this point
how exactly OAuth will leverage TB, but there's potently a case for an
OAuth client acting as an HTTPS client to want to have an token bound
access token that can be used at multiple resource servers, which might be
on different hosts/domains. The privacy concerns that arise from that
situation are already there because the access token is correlatable so
allowing the scope of the TB key to do the same doesn't make things any
worse. It's the same from a privacy perspective, just more secure. Having
HTTPSTB clearly define the public suffix + 1 scope for browsers while still
allowing for cases like that OAuth one might be useful.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 13 May 2016 21:43:38 +0000

Hi Brian,

Ø  Having HTTPSTB clearly define the public suffix + 1 scope for browsers while still allowing for cases like that OAuth one might be useful.
Perhaps the latter (different key scoping for OAuth) should be part of a separate OAUTHTB spec.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, May 13, 2016 2:15 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] HTTPSTB: discuss scoping of token binding keys earlier in the document

I put in https://github.com/TokenBinding/Internet-Drafts/issues/33 but am sending this message to the list too as some/many WG participants don't actively monitor GitHub (as suggested by Andrei). Text of the issue is copied below. Thanks!

As of draft-ietf-tokbind-https-03 in the Privacy Considerations Section 5.1 Scoping of Token Binding Keys <https://tools.ietf.org/html/draft-ietf-tokbind-https-03#section-5.1> is the first real mention that token binding keys/ids should be scoped to public suffix + 1. Though the first sentence in 3.1 hints at it, it's not defined until later.

The scope of where TB keys are sent is a pretty fundamental part of HTTPSTB and, as such, I believe should be defined/discussed in Section 2 along with the Sec-Token-Binding header that the scoping applies to. The Privacy Considerations are still good considerations but then could refer back to the scoping definition in Sec 2 rather than being the definition.

Public suffix + 1 makes sense as the scope for browser user agents but is maybe overly restrictive/prescriptive for some other HTTPS cases. OAuth access tokens come to mind, although it's still up in the air at this point how exactly OAuth will leverage TB, but there's potently a case for an OAuth client acting as an HTTPS client to want to have an token bound access token that can be used at multiple resource servers, which might be on different hosts/domains. The privacy concerns that arise from that situation are already there because the access token is correlatable so allowing the scope of the TB key to do the same doesn't make things any worse. It's the same from a privacy perspective, just more secure. Having HTTPSTB clearly define the public suffix + 1 scope for browsers while still allowing for cases like that OAuth one might be useful.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 13 May 2016 15:49:57 -0600

Agreed, HTTPSTB shouldn't define any scoping for the hypothetical OAUTHTB.
But OAuth also uses HTTPS so having the language in HTTPSTB not preclude
what OAuth might do could be useful.

On Fri, May 13, 2016 at 3:43 PM, Andrei Popov <[email-masked]>
wrote:

> Hi Brian,
>
>
>
> Ø  Having HTTPSTB clearly define the public suffix + 1 scope for browsers
> while still allowing for cases like that OAuth one might be useful.
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Friday, May 13, 2016 2:15 PM
> *To:* IETF Tokbind WG <[email-masked]>
> *Subject:* [Unbearable] HTTPSTB: discuss scoping of token binding keys
> earlier in the document
>
>
>
> As of draft-ietf-tokbind-https-03 in the Privacy Considerations Section
> 5.1 Scoping of Token Binding Keys
> <https://tools.ietf.org/html/draft-ietf-tokbind-https-03#section-5.1>is
> the first real mention that token binding keys/ids should be scoped to
> public suffix + 1. Though the first sentence in 3.1 hints at it, it's not
> defined until later.
>
> The scope of where TB keys are sent is a pretty fundamental part of
> HTTPSTB and, as such, I believe should be defined/discussed in Section 2
> along with the Sec-Token-Binding header that the scoping applies to. The
> Privacy Considerations are still good considerations but then could refer
> back to the scoping definition in Sec 2 rather than being the definition.
>