Subject: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1)

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 18:04:21 +1000

On 5 August 2016 at 12:42, Manger, James
<[email-masked]> wrote:
> Would the alternative be to specify a domain (or origin?) in the token binding negotiation TLS extension, like the cookie "domain" parameter?
> Or is correlation within an eTLD+1 simply the reality of the web?

The alternative is to limit token bindings to a single origin and
accept that token binding only protects cookies for the origin on
which they were originally created.  We've taken great pains to limit
the damage that our shared legacy causes.  I'd rather that token
binding not further entrench the mistakes of cookies.

In this case, I would prefer that this go beyond the host-only
handling for cookies which RFC 6265 defines, by limiting them to the
full RFC 6455 tuple of scheme+host+port.

That means that only the origin that generates the bound cookie can
validate it, but I'm having trouble identifying cases where this would
be anything worse than merely inconvenient for servers to use.

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 8 Aug 2016 14:01:31 +0000

> be anything worse than merely inconvenient for servers to use.

While I favor this proposal, I can't say that I have the full range of use cases in mind since I'm coming to the conversation late. My concerns about the sharing of bindings were mostly motivated by confusion/brain-freeze on my part, so it's nowhere near as bad as I was envisioning.

My guess is that one common scenario this would block is the use of bound domain cookies to implement intra-enterprise SSO, which (minus the token binding) is/was a fairly common practice before the rise of real federation standards, and is still supported today by some commercial and open source SSO software.

I do think it would be unfortunate if there weren't a *way* to limit this, even if it were actually still allowed. It's one thing to say you can share them, but it's another to say you must.

-- Scott

---

From: Brian Campbell <[email-masked]>
Date: Mon, 8 Aug 2016 12:13:48 -0600

Even with real federated SSO standards, using domain cookie(s) to track
authenticated end-user state is very very common for intra-enterprise SSO
and on different sites/services on larger web properties (I presume,
anyway, from the many .bigcompany.com cookies I have in my browser).  The
the eTLD+1 scoping is pragmatic and useful and, with it, Token Binding can
improve the security of such deployments. Scoping tighter than that would
be much more than merely inconvenient - it would require re-architecture of
many intra-domain SSO deployments and/or impede the adoption of Token
Binding.

On Mon, Aug 8, 2016 at 8:01 AM, Cantor, Scott <[email-masked]> wrote:

> While I favor this proposal, I can't say that I have the full range of use
> cases in mind since I'm coming to the conversation late. My concerns about
> the sharing of bindings were mostly motivated by confusion/brain-freeze on
> my part, so it's nowhere near as bad as I was envisioning.
>
> My guess is that one common scenario this would block is the use of bound
> domain cookies to implement intra-enterprise SSO, which (minus the token
> binding) is/was a fairly common practice before the rise of real federation
> standards, and is still supported today by some commercial and open source
> SSO software.
>
> I do think it would be unfortunate if there weren't a *way* to limit this,
> even if it were actually still allowed. It's one thing to say you can share
> them, but it's another to say you must.
>
> -- Scott
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 8 Aug 2016 18:26:31 +0000

> and on different sites/services on larger web properties (I presume, anyway,
> from the many .bigcompany.com cookies I have in my browser).

And hey, it helps you track people too...

> The the eTLD+1 scoping is pragmatic and useful and, with it,
> Token Binding can improve the security of such deployments.

I'm just agreeing with the sentiment that it kind of sucks to *require* it. It's a complexity / privacy trade-off, obviously.

I would hope that if a cookie spec were invented today, proposing that only eTLD+1 scoping be supported would have been negatively received.

-- Scott

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2016 14:38:26 -0400

No Hat.

I tend to agree with Brian.

I know of lots of Web Access Management type applications that use these sorts of cookies for session extension and other things.

I think having different rules for Token Binding and cookies would likely hurt adoption.

However I am sensitive to unintended correlation.

Martin do you have some idea how a token bound cookie set by x.example.com could be validated by y.example.com under a strict same origin policy.

It strikes me that if you could then you haven’t stopped correlation, but perhaps you have a idea how to do that.
If we are only talking inconvenience I might be convinced, but impossible is a larger issue.

My biggest privacy concern is the theft and re use of the cookies, saying some cookies cant be protected is a hard sell.

Regards
John B.

> On Aug 8, 2016, at 2:13 PM, Brian Campbell <[email-masked]> wrote:
> 
> Even with real federated SSO standards, using domain cookie(s) to track authenticated end-user state is very very common for intra-enterprise SSO and on different sites/services on larger web properties (I presume, anyway, from the many .bigcompany.com <http://bigcompany.com/> cookies I have in my browser).  The the eTLD+1 scoping is pragmatic and useful and, with it, Token Binding can improve the security of such deployments. Scoping tighter than that would be much more than merely inconvenient - it would require re-architecture of many intra-domain SSO deployments and/or impede the adoption of Token Binding.  
> 
> On Mon, Aug 8, 2016 at 8:01 AM, Cantor, Scott <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Aug 2016 12:14:43 +1000

On 9 August 2016 at 04:38, John Bradley <[email-masked]> wrote:
> Martin do you have some idea how a token bound cookie set by x.example.com
> could be validated by y.example.com under a strict same origin policy.

So x sets a cookie bound to key Kx.  Only x can validate that key
because the client doesn't use that key with other parties.  That
means that y needs to get the client to prove possession of (the
private key for) Kx.

With the help of x, it can easily do this with a referred token
binding.  y makes the client make a request to x, and x redirects back
to y with the <really-long-header-field-name-that-triggers-referred-token-binding>
header field set.  Then y is able to acquire proof from the client
that it owns Kx.

This only requires that y support the same signature schemes as x, and
that y has help from x.

Sure, this is inconvenient (it's round trips), but this establishes
possible.  And, once you have this proof, you might be able to store
the mapping between Kx and Ky.

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 10 Aug 2016 07:44:10 +0000

Google sets an authentication cookie on *.google.com. We also set a variety
of authentication-related cookies on more narrowly-defined domains, but
it's that domain cookie that we channel-bind.

Sometimes users arrive at, say, mail.google.com through a redirect from
accounts.google.com (which mints the domain cookie) and in that case it's
theoretically possible that they could arrive there with a referred token
binding from accounts.google.com. So let's say a request comes into
mail.google.com with provided token binding Kx, referred token binding Ky,
and the cookie is bound to Ky. mail.google.com now would have to remember
that Kx is also a valid token binding key for this cookie - presumably by
mutating the cookie (or its associated session information on the server).
Gmail can't write/mutate our authentication cookies - only our
authentication infrastructure can do this. Not an insurmountable problem,
but likely one that's big enough for gmail (and maps, and docs, etc.) to
conclude that they shouldn't bother with channel binding.

Then there are the cases in which users arrive at our destination services (
mail.google.com, maps.google.com, etc.) directly by typing the URL into
their browser. In that case the service won't have the benefit of seeing
the referred token binding, so the cookie will simply count as mismatched.
Incurring the extra redirect in this case to accounts.google.com and back
is again something that the various teams and services are not likely
willing to pay.

In conclusion, moving to an origin scope for token-binding keys would
likely mean for a company like Google, which has big complicated old
systems that are hard to change, that we couldn't in practice deploy it.

Dirk.

On Mon, Aug 8, 2016 at 7:14 PM Martin Thomson <[email-masked]>
wrote:

> to y with the
> <really-long-header-field-name-that-triggers-referred-token-binding>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 10 Aug 2016 17:37:06 +0000

Yes, the extra round-trips would be a deployment blocker in many cases. Generally, I think that scoping TB keys narrower than the tokens they protect would cause problems.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Dirk Balfanz
Sent: Wednesday, August 10, 2016 12:44 AM
To: Martin Thomson <[email-masked]>; John Bradley <[email-masked]>
Cc: Subodh Iyengar <[email-masked]>; Scott Cantor <[email-masked]>; IETF Tokbind WG <[email-masked]>; Brian Campbell <[email-masked]>; Manger, James <[email-masked]>; Nick Harper <[email-masked]>
Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1)

Google sets an authentication cookie on *.google.com<http://google.com>. We also set a variety of authentication-related cookies on more narrowly-defined domains, but it's that domain cookie that we channel-bind.

Sometimes users arrive at, say, mail.google.com<http://mail.google.com> through a redirect from accounts.google.com<http://accounts.google.com> (which mints the domain cookie) and in that case it's theoretically possible that they could arrive there with a referred token binding from accounts.google.com<http://accounts.google.com>. So let's say a request comes into mail.google.com<http://mail.google.com> with provided token binding Kx, referred token binding Ky, and the cookie is bound to Ky. mail.google.com<http://mail.google.com> now would have to remember that Kx is also a valid token binding key for this cookie - presumably by mutating the cookie (or its associated session information on the server). Gmail can't write/mutate our authentication cookies - only our authentication infrastructure can do this. Not an insurmountable problem, but likely one that's big enough for gmail (and maps, and docs, etc.) to conclude that they shouldn't bother with channel binding.

Then there are the cases in which users arrive at our destination services (mail.google.com<http://mail.google.com>, maps.google.com<http://maps.google.com>, etc.) directly by typing the URL into their browser. In that case the service won't have the benefit of seeing the referred token binding, so the cookie will simply count as mismatched. Incurring the extra redirect in this case to accounts.google.com<http://accounts.google.com> and back is again something that the various teams and services are not likely willing to pay.

In conclusion, moving to an origin scope for token-binding keys would likely mean for a company like Google, which has big complicated old systems that are hard to change, that we couldn't in practice deploy it.

Dirk.

On Mon, Aug 8, 2016 at 7:14 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
On 9 August 2016 at 04:38, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
> Martin do you have some idea how a token bound cookie set by x.example.com<http://x.example.com>
> could be validated by y.example.com<http://y.example.com> under a strict same origin policy.

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 10 Aug 2016 17:43:15 +0000

> Yes, the extra round-trips would be a deployment blocker in many cases.
> Generally, I think that scoping TB keys narrower than the tokens they protect
> would cause problems.

And there's no feasible way for a deployer to configure a server with the required scoping to inform the client? Even if federation didn't work in a practical way in this kind of scenario because of the cross-server issues, just the ability to do it for directly issued cookies would still be a benefit to privacy.

-- Scott

---

From: John Bradley <[email-masked]>
Date: Wed, 10 Aug 2016 14:15:45 -0400

No Hat

Scott, are you suggesting that that be done on a per cookie basis, or as something that the server would advertise in say a header that would allow the browser to more tightly scope its bindings.

It might be possible to have a default exact match but have a flag that the browser could check to see if it should use eTLD+1.  

That would allow the server to control it, however it runs the risk of different servers publishing conflicting rules and causing issues.

Completely scraping eTLD+1 seems like it would hurt deployment.

How do people feel about a configuration flag of some sort for the server and having a default.

Thoughts?

One other thing while I am at it.

I have been looking at using Token Binding in OAuth.

Because RSA Token binding ID are so large we are probably going to need a thumbprint of them to put in tokens to keep the size from blowing up.

This adds complexity over saying just send the token binding ID.

So stepping back it is tempting to just say use the token binding iD and strongly recommend EC keys as RSA ones really are only for backwards compatibility and the size may cause things to break.

My question is really backwards compatibility with what?   Wouldn't it be better to not try and support RSA and go all EC from the start.   RSA seems unlikely to be used in the real world as almost all of the infrastructure is new and EC is the better choice.

Wouldn’t it be better to have developers spend time on doing two curve options rather than RSA.  

Ditching RSA at this point may gore some ox at this point, however dropping it might lower the complexity of some implementations as they won’t need to worry about RSA.

It also somewhat simplifies key migration in the short term.   RSA just don’t do it.

Thoughts

John B.

> On Aug 10, 2016, at 1:43 PM, Cantor, Scott <[email-masked]> wrote:
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 10 Aug 2016 18:25:56 +0000

> Scott, are you suggesting that that be done on a per cookie basis, or as
> something that the server would advertise in say a header that would allow
> the browser to more tightly scope its bindings.

Not per-cookie (that would couple the layers intolerably). I'm suggesting a server deployment that was understood to be serving only cookies that are origin-scoped could be configured to match that in the TokenBinding layer by advertising that to the client. I would assume that would be in the TLS handshake and not in an HTTP header, but I'm not versed enough yet to know if a header would work.

> That would allow the server to control it, however it runs the risk of different
> servers publishing conflicting rules and causing issues.

If you servers in a common pool, sure, but that's a bug. Servers that are unrelated to each other would be signaling a different expectation.

> Completely scraping eTLD+1 seems like it would hurt deployment.

Don't think anybody has suggested that, and if it goes further and turns out that federated tokens essentially demand it, so be it.

> Because RSA Token binding ID are so large we are probably going to need a
> thumbprint of them to put in tokens to keep the size from blowing up.

> My question is really backwards compatibility with what?   Wouldn't it be
> better to not try and support RSA and go all EC from the start.   RSA seems
> unlikely to be used in the real world as almost all of the infrastructure is new
> and EC is the better choice.

This is the EC that's constantly compiled out of libraries on popular Linux distros (this is admittedly waning) and is missing from half the OpenJDK packages out there?

-- Scott

---

From: Andrei Popov <[email-masked]>
Date: Wed, 10 Aug 2016 19:04:23 +0000

To step back a bit, TB specs explicitly avoid specifying methods of binding tokens, although they do provide examples of what could be done.

Even if we were to prohibit RSA, we can’t guard against a future algorithm that requires a long key.

The simple solution is to hash the TB IDs, and it works regardless of the key type. It is also possible that Bill’s idea would work, as an alternative. But IMHO this belongs in a higher-level spec.

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Wednesday, August 10, 2016 11:47 AM
To: John Bradley <[email-masked]>
Cc: Scott Cantor <[email-masked]>; Andrei Popov <[email-masked]>; Subodh Iyengar <[email-masked]>; Dirk Balfanz <[email-masked]>; Manger, James <[email-masked]>; IETF Tokbind WG <[email-masked]>; Brian Campbell <[email-masked]>; Martin Thomson <[email-masked]>; Nick Harper <[email-masked]>
Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1)

On Wed, Aug 10, 2016 at 11:15 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
I have been looking at using Token Binding in OAuth.

Minimizing token size is important, so I'd prefer just to have a 64-bit fingerprint if possible.  To do that without creating the risk that attackers can create key pairs that have the same fingerprint, you have to randomize the hashing with a secret of some sort.  If this fingerprint is in an encrypted portion of an oauth token, then the randomization key can be derived from the decryption key, or something like that.

If we instead store the uncompresed EC keys, it will take 64-bytes, 8X larger than required.

Just some dome brainstorming: what if we encrypted the oauth token or cookie using the standard encryption key hashed with the TB public key?  That way we verify the TB key by successfully decrypting the token, without increasing the size of the cookie/token at all.  I think this falls under the concept of AEAD, where the TB public key is simply "additional data".

Bill

---

From: Bill Cox <[email-masked]>
Date: Wed, 10 Aug 2016 11:47:28 -0700

> This adds complexity over saying just send the token binding ID.

Minimizing token size is important, so I'd prefer just to have a 64-bit
fingerprint if possible.  To do that without creating the risk that
attackers can create key pairs that have the same fingerprint, you have to
randomize the hashing with a secret of some sort.  If this fingerprint is
in an encrypted portion of an oauth token, then the randomization key can
be derived from the decryption key, or something like that.

If we instead store the uncompresed EC keys, it will take 64-bytes, 8X
larger than required.

Just some dome brainstorming: what if we encrypted the oauth token or
cookie using the standard encryption key hashed with the TB public key?
That way we verify the TB key by successfully decrypting the token, without
increasing the size of the cookie/token at all.  I think this falls under
the concept of AEAD, where the TB public key is simply "additional data".

Bill

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 10 Aug 2016 22:30:49 +0300

> the concept of AEAD, where the TB public key is simply "additional data".

Those two ideas are rather different. 

One could stick the TB into key derivation (having key derivation is
also useful to expand the often-anemic nonces spaces of various AEADs
(12 octets isn't even remotely enough)).

Or one could stick the TB as associated data (but if one doesn't have
key derivation, using AEADs safely is rather hard, MRAEs are another
matter).

In both cases, if TB doesn't match, you get decryption failure, and
neither expands cookie beyond what the standard encryption would do.

Analogs to both ideas also work with VecMACs, if one does not need
encryption.

-Ilari

---

From: John Bradley <[email-masked]>
Date: Wed, 10 Aug 2016 16:03:17 -0400

The representation of the token binding ID in a OAuth Token or ID_Token would be a higher level spec.  We did introduce those to the OAuth WG.

I think it was you or Dirk that argued that we should keep it simple and just pass the whole opaque token binding ID both in the token and when we needed to refer to it in a parameter.

In those specs we initially defined a SHA 256 thumbprint of the token binding ID.  To carry as a claim for the proof of possession.

For cookies using the token binding_id as part of the encryption or signing key via key derivation seems like a reasonable approach for long keys. 

For OAuth there are downsides to using and maintaining symmetric keys.   Signing the tokens with asymmetric keys has big advantages in simplifying key distribution and rotation.

I think carrying some representation of the key in the token will be required for a good number of the use cases.

However the encryption idea is interesting for cookies.

So Andre,  I take it that you think dropping RSA at this point is not worth it as we are going to want to have short representations of keys in the higher level specs anyway?

We are currently recommending that servers support both RSA and EC.  

Are we thinking that some clients would only be able to support RSA?

I am guessing that browsers will all have EC and I suspect Windows and CroNet will have EC.

So yes I am being provocative, but I would like to have a answer that the WG has thought through on the list about why we are doing RSA before we get to the IESG and someone asks the question.

John B.
> On Aug 10, 2016, at 3:04 PM, Andrei Popov <[email-masked]> wrote:
> 
> On Wed, Aug 10, 2016 at 11:15 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Wed, 10 Aug 2016 15:39:31 -0600

On Wed, Aug 10, 2016 at 12:25 PM, Cantor, Scott <[email-masked]> wrote:

> Don't think anybody has suggested that,
>

I believe that is the very suggestion that started this thread (also issue
#69 <https://github.com/TokenBinding/Internet-Drafts/issues/69>) and is
what I and a few others are pushing back on.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 10 Aug 2016 15:44:04 -0600

On Wed, Aug 10, 2016 at 12:15 PM, John Bradley <[email-masked]> wrote:

> It might be possible to have a default exact match but have a flag that
> the browser could check to see if it should use eTLD+1.
>
> That would allow the server to control it, however it runs the risk of
> different servers publishing conflicting rules and causing issues.
>

I'm pretty squarely in the eTLD+1 is just fine camp. But I wouldn't be
opposed to exploring something like this, which I think might have to
happen during negotiation.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 10 Aug 2016 16:06:59 -0600

+1

On Wed, Aug 10, 2016 at 1:04 PM, Andrei Popov <[email-masked]>
wrote:

>
> The simple solution is to hash the TB IDs, and it works regardless of the
> key type.
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 10 Aug 2016 15:45:05 -0600

+1

---

From: Andrei Popov <[email-masked]>
Date: Wed, 10 Aug 2016 22:13:21 +0000

Ø  So Andre,  I take it that you think dropping RSA at this point is not worth it as we are going to want to have short representations of keys in the higher level specs anyway?
Yes, I think there are good reasons to have short representations of keys regardless of the algorithm. Even if we were to drop RSA now, we may have to use long keys with a future algorithm.

Ø  So yes I am being provocative, but I would like to have a answer that the WG has thought through on the list about why we are doing RSA before we get to the IESG and someone asks the question.
Ideally, we want our TB keys hardware bound, and unfortunately a variety of hardware devices (notably, TPMs) don’t support EC.

Cheers,

Andrei

From: John Bradley [mailto:[email-masked]]
Sent: Wednesday, August 10, 2016 1:00 PM
To: Andrei Popov <[email-masked]>
Cc: Bill Cox <[email-masked]>; Scott Cantor <[email-masked]>; Subodh Iyengar <[email-masked]>; Dirk Balfanz <[email-masked]>; Manger, James <[email-masked]>; IETF Tokbind WG <[email-masked]>; Brian Campbell <[email-masked]>; Martin Thomson <[email-masked]>; Nick Harper <[email-masked]>
Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1)

John B.

On Aug 10, 2016, at 3:04 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Wednesday, August 10, 2016 11:47 AM
To: John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: Scott Cantor <[email-masked]<mailto:[email-masked]>>; Andrei Popov <[email-masked]<mailto:[email-masked]>>; Subodh Iyengar <[email-masked]<mailto:[email-masked]>>; Dirk Balfanz <[email-masked]<mailto:[email-masked]>>; Manger, James <[email-masked]<mailto:[email-masked]>>; IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>; Brian Campbell <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Nick Harper <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1)

Bill

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 10 Aug 2016 23:04:36 +0000

On 8/10/16, 5:39 PM, "Brian Campbell" <[email-masked]> wrote:

> I believe that is the very suggestion that started this thread (also 
>    issue #69 <https://github.com/TokenBinding/Internet-Drafts/issues/69>) and is what I
> and a few others are pushing back on. 

Ok, *I* wasn't suggesting it. While I think cookies are broken, I don't think one can strengthen them without parity in various respects.

-- Scott

---

From: John Bradley <[email-masked]>
Date: Wed, 10 Aug 2016 18:55:44 -0400

Good point about the hardware support.

That might be worth documenting someplace, so that people later understand why we made the choice.

Use RSA if you have hardware support for it and not EC.  If you are using a software keystore EC should be preferred for size.

Something like that.

Otherwise people will wonder when to use one over the other.

John B.
> On Aug 10, 2016, at 6:13 PM, Andrei Popov <[email-masked]> wrote:
> 
> On Aug 10, 2016, at 3:04 PM, Andrei Popov <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: Bill Cox [mailto:[email-masked] <mailto:[email-masked]>] 
> To: John Bradley <[email-masked] <mailto:[email-masked]>>
> Cc: Scott Cantor <[email-masked] <mailto:[email-masked]>>; Andrei Popov <[email-masked] <mailto:[email-masked]>>; Subodh Iyengar <[email-masked] <mailto:[email-masked]>>; Dirk Balfanz <[email-masked] <mailto:[email-masked]>>; Manger, James <[email-masked] <mailto:[email-masked]>>; IETF Tokbind WG <[email-masked] <mailto:[email-masked]>>; Brian Campbell <[email-masked] <mailto:[email-masked]>>; Martin Thomson <[email-masked] <mailto:[email-masked]>>; Nick Harper <[email-masked] <mailto:[email-masked]>>

---

From: John Bradley <[email-masked]>
Date: Wed, 10 Aug 2016 19:30:13 -0400

No Hat.

I think it was Martin’s suggestion to move to strict same origin.   

You asked the question so are guilty by association:)

Personally I have sort of mixed feelings about this.

Moving to server configurable token binding scoping really only helps the people who aren’t going to participate in correlation anyway not collect information that could be used for correlation.

It seems a bit like some governments who mandate the use of persistent subjects (pair wise) to avoid correlation but at the same time require a matching data set of attributes that includes full name birthdate and address.  

Any bad guy wanting to correlate in side of a eTLD+1 can just use a cooke or change the token binding setting to use that origin.

If I thought that the scoping rules for cookies were likely to change being more conservative with token binding would make no more sense.

Changing from eTLD+1 seems politicly correct, but on the other hand may just be theatre.

Can anyone come up with some real privacy increase that we can achieve that would not easily be circumvented by anyone wanting to correlate.

I would like to have a concrete threat so that we can judge if any mitigation we propose might be effective.

John B.

> On Aug 10, 2016, at 7:04 PM, Cantor, Scott <[email-masked]> wrote:
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 11 Aug 2016 00:09:31 +0000

On 8/10/16 7:30 PM, John Bradley wrote:

> Can anyone come up with some real privacy increase that we can achieve
> that would not easily be circumvented by anyone wanting to correlate.

I think one response is that there are people who build tools for
browsers that impose stronger constraints than the ones the browser
vendors are willing to impose themselves.

You're probably right that there's little point in forcing discipline on
the server side, but it seems like the client ought to have the freedom
to be configured to do a better job.

So, yes, I can come up with an increase: give me a browser I can tell
not to mint eTLD+1 keys if I want to, so that if I also want to tell it
not to accept eTLD+1 cookies, that hasn't been subverted.

-- Scott

---

From: John Bradley <[email-masked]>
Date: Wed, 10 Aug 2016 20:14:45 -0400

I can see value in tying the two together in the browser so that if the browser doesn’t accept cookies with that origin then it would restrict the token binding to same origin as well.

That implementation advice for the browsers may be a reasonable idea.

Letting the server signal the restriction is a bit fox in charge of the hen house.

Thanks for the input.

John B.
> On Aug 10, 2016, at 7:50 PM, Cantor, Scott <[email-masked]> wrote:
>

---

From: "Manger, James" <[email-masked]>
Date: Thu, 11 Aug 2016 13:54:34 +1000

[Dirk Balfanz wrote] In conclusion, moving to an origin scope for token-binding keys would likely mean for a company like Google, which has big complicated old systems that are hard to change, that we couldn't in practice deploy it.

This is the sort of reason to accept eTLD+1 scoping. Details about how Google use Channel IDs (the precursor to this work) would be even more compelling. Do mail.google.com and accounts.google.com use a shared Channel ID to protect login cookies today? I assume Chrome uses eTLD+1 scope for Channel IDs as recommended by draft-balfanz-tls-channelid-01<https://tools.ietf.org/html/draft-balfanz-tls-channelid-01#section-8>? From the cookie data in my Chrome browser I see that google.com has a Channel ID, while mail.google.com doesn’t mention one (but it probably only gets mentioned at the top-level).

Curiously, dozens of *.googleapis.com sites use separate Channel IDs (even when they are closely related, eg mts0. and mts1.) as googleapis.com is listed as a public suffix.

[Andrei Popov wrote] Generally, I think that scoping TB keys narrower than the tokens they protect would cause problems.

True. But a major class of tokens to protect are federated identity tokens whose scope is a pair of unrelated domains (IdP & RP) so even the eTLD+1 rule “would cause problems”. That problem is solved by adding the complexity of the referred-token mechanism.

Perhaps the scope issue could be explained by saying: “From a privacy perspective, token binding is vaguely equivalent to a server setting a cookie as follows:

  Set-Cookie: id=<client-chosen-random-value>; Domain=<one-label>.<eTLD>; Expires=Fri, 31 Dec 9999 23:59:59 GMT; Secure; HttpOnly

Such a cookie doesn’t feel like best practice, but it is silently allowed by browsers so using eTLD+1 as the hardwired scope for TB keys is a reasonable pragmatic choice.

--
James Manger

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 11 Aug 2016 06:29:41 +0000

On Wed, Aug 10, 2016 at 8:54 PM Manger, James <
[email-masked]> wrote:

> [Dirk Balfanz wrote] In conclusion, moving to an origin scope for
> token-binding keys would likely mean for a company like Google, which has
> big complicated old systems that are hard to change, that we couldn't in
> practice deploy it.
>
>
>
> This is the sort of reason to accept eTLD+1 scoping. Details about how
> Google use Channel IDs (the precursor to this work) would be even more
> compelling. Do mail.google.com and accounts.google.com use a shared
> Channel ID to protect login cookies today? I assume Chrome uses eTLD+1
> scope for Channel IDs as recommended by draft-balfanz-tls-channelid-01
> <https://tools.ietf.org/html/draft-balfanz-tls-channelid-01#section-8>?
> From the cookie data in my Chrome browser I see that google.com has a
> Channel ID, while mail.google.com doesn’t mention one (but it probably
> only gets mentioned at the top-level).
>

Yes, you are correct. Chrome uses the same ChannelID key for *.google.com

> Curiously, dozens of *.googleapis.com sites use separate Channel IDs
> (even when they are closely related, eg mts0. and mts1.) as googleapis.com
> is listed as a public suffix.
>

Again correct. googleapis.com is in the PSL, so every sub-domain gets its
own ChannelID key. Fortunately, we don't set authentication cookies on
those domains, or else the channel-binding team at Google would be in
trouble. ;-)

Dirk.

[Andrei Popov wrote] Generally, I think that scoping TB keys narrower than
> the tokens they protect would cause problems.
>
>
>
> True. But a major class of tokens to protect are federated identity tokens
> whose scope is a pair of unrelated domains (IdP & RP) so even the eTLD+1
> rule “would cause problems”. That problem is solved by adding the
> complexity of the referred-token mechanism.
>
>
>
>
>
> Perhaps the scope issue could be explained by saying: “From a privacy
> perspective, token binding is vaguely equivalent to a server setting a
> cookie as follows:
>
>
>
>   Set-Cookie: id=<client-chosen-random-value>; Domain=<one-label>.<eTLD>;
> Expires=Fri, 31 Dec 9999 23:59:59 GMT; Secure; HttpOnly
>
>
>
> Such a cookie doesn’t feel like best practice, but it is silently allowed
> by browsers so using eTLD+1 as the hardwired scope for TB keys is a
> reasonable pragmatic choice.
>
>
>
> --
>
> James Manger
>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 10 Aug 2016 23:39:52 -0700

On Wed, Aug 10, 2016 at 8:54 PM, Manger, James
<[email-masked]> wrote:
> compelling. Do mail.google.com and accounts.google.com use a shared Channel
> ID to protect login cookies today? I assume Chrome uses eTLD+1 scope for
> Channel IDs as recommended by draft-balfanz-tls-channelid-01? From the
> cookie data in my Chrome browser I see that google.com has a Channel ID,
> while mail.google.com doesn’t mention one (but it probably only gets
> mentioned at the top-level).
>
>
>
> Curiously, dozens of *.googleapis.com sites use separate Channel IDs (even
> when they are closely related, eg mts0. and mts1.) as googleapis.com is
> listed as a public suffix.
>
>
>
>
>
> rule “would cause problems”. That problem is solved by adding the complexity
> of the referred-token mechanism.

Why doesn't Oauth solve this/why do we need to solve it? We should be
allowed to be better cookies, and not asked to do more.
Simplify, simplify, simplify.

---

From: "Manger, James" <[email-masked]>
Date: Thu, 11 Aug 2016 17:13:17 +1000

>> [Andrei Popov wrote] Generally, I think that scoping TB keys narrower 
>> than the tokens they protect would cause problems.
>>
>>
>>
>> True. But a major class of tokens to protect are federated identity 
>> tokens whose scope is a pair of unrelated domains (IdP & RP) so even 
>> the eTLD+1 rule “would cause problems”. That problem is solved by 
>> adding the complexity of the referred-token mechanism.

> Why doesn't Oauth solve this/why do we need to solve it? We should be allowed to be better cookies, and not asked to do more.

Because one item in the main design objectives for the Token Binding group charter [https://tools.ietf.org/wg/tokbind/charters] is:
"3. Support both first-party and federation scenarios"

Because the OAuth group cannot build federation support if the only primitive available is eTLD+1 scoped crypto cookies.

--
James Manger

---

From: Watson Ladd <[email-masked]>
Date: Thu, 11 Aug 2016 06:20:08 -0700

> Because the OAuth group cannot build federation support if the only primitive available is eTLD+1 scoped crypto cookies.

Bear in mind OAuth works today, via a bunch of redirects. No reason
that can't continue to work. To use with tokenbinding, switch the
local session cookie to a token bound token. What's the problem?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: John Bradley <[email-masked]>
Date: Thu, 11 Aug 2016 09:47:31 -0400

That could conceivably work,  however I suspect that that requires a much larger reworking of web sites than just token binding the cookies.  

I think some would argue that restricting token binding to same origin and forcing people to use OAuth to replace eTLD+1 cookies is not really a simplification for the application developers, though it might be for the browser developers.

It is an adoption question.

John B.
> On Aug 11, 2016, at 9:20 AM, Watson Ladd <[email-masked]> wrote:
>