Subject: [Unbearable] support for different key parameters within the same TLD+1

From: Brian Campbell <[email-masked]>
Date: Thu, 4 Aug 2016 16:22:10 -0600

It's possible (maybe even likely) that different servers supporting
different TokenBindingKeyParameters will be deployed in the same TLD+1.

I'm wondering if more guidance is needed around expected or desired
behavior in such circumstances?

For example, let's say a browser that supports all three key parameters has
already established an ecdsap256 token binding with one.example.com. When
it goes to make a request to two.example.com, should it offer only
ecdsap256 in the key_parameters_list of the token_binding TLS extension? Or
should it offer all supported key parameters in the key_parameters_list?
The latter might imply that multiple Token Binding IDs are maintained by
the client per TLD+1.

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 4 Aug 2016 22:29:51 +0000

Nick and I were chatting about this particular case and the problem is a bit worse and a lot of guidance is needed for this. For example if you do non overlapping token bindings on different domains within one TLD + 1 and share a cert between them, if a browser coalesces connections between the domains since their identity would be correct, token binding would fail.

Subodh
________________________________
From: Unbearable [[email-masked]] on behalf of Brian Campbell [[email-masked]]
Sent: Thursday, August 04, 2016 3:22 PM
To: IETF Tokbind WG
Subject: [Unbearable] support for different key parameters within the same TLD+1

It's possible (maybe even likely) that different servers supporting different TokenBindingKeyParameters will be deployed in the same TLD+1.

I'm wondering if more guidance is needed around expected or desired behavior in such circumstances?

For example, let's say a browser that supports all three key parameters has already established an ecdsap256 token binding with one.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__one.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=krCYwCll_BftIp3KF2AYjSqEiZW6nJWbRla-q-moZIs&s=ybtrfKIGcb4pybfGqFd_2EDioM1xJI7riy76vsZrbw0&e=>. When it goes to make a request to two.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__two.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=krCYwCll_BftIp3KF2AYjSqEiZW6nJWbRla-q-moZIs&s=jZSwrGXOxs9CzJ0JAgIErIMbDohpSwJrneleF4v1fo0&e=>, should it offer only ecdsap256 in the key_parameters_list of the token_binding TLS extension? Or should it offer all supported key parameters in the key_parameters_list? The latter might imply that multiple Token Binding IDs are maintained by the client per TLD+1.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 4 Aug 2016 16:44:30 -0600

My thinking about this was admittedly sparked by the migration thread
between you and Nick (I'm still thinking about migration BTW).

Forgive my ignorance here but how could browser coalesces connections to
different domains if they are on different hosts (different IP addresses)?
I guess I'm making the assumption that supported key parameters will be
consistent per host at least.

Ultimately though I guess we are on the same page that some additional
guidance would be useful.

On Thu, Aug 4, 2016 at 4:29 PM, Subodh Iyengar <[email-masked]> wrote:

> Nick and I were chatting about this particular case and the problem is a
> bit worse and a lot of guidance is needed for this. For example if you do
> non overlapping token bindings on different domains within one TLD + 1 and
> share a cert between them, if a browser coalesces connections between the
> domains since their identity would be correct, token binding would fail.
>
> Subodh
> ------------------------------
> *From:* Unbearable [[email-masked]] on behalf of Brian
> Campbell [[email-masked]]
> *Sent:* Thursday, August 04, 2016 3:22 PM
> *To:* IETF Tokbind WG
> *Subject:* [Unbearable] support for different key parameters within the
> same TLD+1
>
> For example, let's say a browser that supports all three key parameters
> has already established an ecdsap256 token binding with one.example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__one.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=krCYwCll_BftIp3KF2AYjSqEiZW6nJWbRla-q-moZIs&s=ybtrfKIGcb4pybfGqFd_2EDioM1xJI7riy76vsZrbw0&e=>.
> When it goes to make a request to two.example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__two.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=krCYwCll_BftIp3KF2AYjSqEiZW6nJWbRla-q-moZIs&s=jZSwrGXOxs9CzJ0JAgIErIMbDohpSwJrneleF4v1fo0&e=>,
> should it offer only ecdsap256 in the key_parameters_list of the
> token_binding TLS extension? Or should it offer all supported key
> parameters in the key_parameters_list? The latter might imply that multiple
> Token Binding IDs are maintained by the client per TLD+1.
>
>
>

---

From: Nick Harper <[email-masked]>
Date: Thu, 4 Aug 2016 15:49:02 -0700

I definitely think that more guidance is needed around what key parameters
a client should advertise if it already has one key for that domain.

If the same IP address is used to host multiple domains, and the cert
covers multiple domains (e.g. one.example.com and two.example.com), then an
H2 client can coalesce connections for one.example.com and two.example.com
- i.e. use one connection for requests on both domains. My assumption is
that if two domains are co-hosted like that, then they will support the
same token binding key parameters (otherwise they'd be changing what they
put in the server negotiation extension based on what the client sends in
SNI, but otherwise sending the same cert, which seems a bit odd to me).

On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell <[email-masked]>
wrote:

>> has already established an ecdsap256 token binding with one.example.com.
>> When it goes to make a request to two.example.com, should it offer only
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 4 Aug 2016 23:53:30 +0000

The Http2 spec allows this connection coalescing to happen. You can run 2 different origins on the same IP address. Servers already use SNI information to determine which certificate to serve, similarly servers could also use this to determine what token binding params could be negotiated. I'm definitely not endorsing this behavior :), but that it's possible.

I agree with Nick and also think a section like Token binding deployment advice would go a long way to prevent silly mistakes from service owners. This section could possibly say that you should use the same token bindings for all domains within the eTLD + 1. It could also include guidance on migrating token binding params as well which we're discussing on another thread.

Subodh
________________________________
From: Nick Harper [[email-masked]]
Sent: Thursday, August 04, 2016 3:49 PM
To: Brian Campbell
Cc: Subodh Iyengar; IETF Tokbind WG
Subject: Re: [Unbearable] support for different key parameters within the same TLD+1

I definitely think that more guidance is needed around what key parameters a client should advertise if it already has one key for that domain.

If the same IP address is used to host multiple domains, and the cert covers multiple domains (e.g. one.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__one.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=Xz0qySs-UD_mfh0z8Y4P0X-23AGDMCfXabDRKhCO4yI&e=> and two.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__two.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=drxkM18T-I8dsXPCyuEHY6ykK_AaBn-Ej6SpUEZMOvU&e=>), then an H2 client can coalesce connections for one.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__one.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=Xz0qySs-UD_mfh0z8Y4P0X-23AGDMCfXabDRKhCO4yI&e=> and two.example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__two.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=drxkM18T-I8dsXPCyuEHY6ykK_AaBn-Ej6SpUEZMOvU&e=> - i.e. use one connection for requests on both domains. My assumption is that if two domains are co-hosted like that, then they will support the same token binding key parameters (otherwise they'd be changing what they put in the server negotiation extension based on what the client sends in SNI, but otherwise sending the same cert, which seems a bit odd to me).

On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
My thinking about this was admittedly sparked by the migration thread between you and Nick (I'm still thinking about migration BTW).

Forgive my ignorance here but how could browser coalesces connections to different domains if they are on different hosts (different IP addresses)? I guess I'm making the assumption that supported key parameters will be consistent per host at least.

Ultimately though I guess we are on the same page that some additional guidance would be useful.

Subodh

For example, let's say a browser that supports all three key parameters has already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.com, should it offer only ecdsap256 in the key_parameters_list of the token_binding TLS extension? Or should it offer all supported key parameters in the key_parameters_list? The latter might imply that multiple Token Binding IDs are maintained by the client per TLD+1.

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=xJqwvIqcoVDiM2tkLv66sXkZtUzI6z7PVT5_vdvOwqg&e=>listinfo/unbearable

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 5 Aug 2016 00:05:02 +0000

> I agree with Nick and also think a section like Token binding deployment
> advice would go a long way to prevent silly mistakes from service owners.
> This section could possibly say that you should use the same token bindings
> for all domains within the eTLD + 1.

I trust it's understood that at a large organization, there is no way to assume any relationship whatsoever between one.osu.edu and two.osu.edu. Different software, departments, operating policies, everything. They may as well not be related.

This spec doesn't assume that a binding to one is equivalent to the other, does it? That would be...really unfortunate.

-- Scott

---

From: Nick Harper <[email-masked]>
Date: Thu, 4 Aug 2016 17:11:37 -0700

The HTTPSTB spec says that token binding keys must be scoped at eTLD+1
(section 2.1). This means that if one.osu.edu and two.osu.edu support the
same key params, a client will use the same token binding key with both.
This is required so that token binding keys are scoped at the same level as
cookies. The two domains are free to negotiate different key params if they
want.

The concern around H2 coalescing only applies if the two domain names point
to the same IP address and the certificate lists both domain names in the
SAN. If those conditions are met, I think it's reasonable to assume that
there's a relationship between them, and require the two domains to
negotiate the same token binding key params.

On Thu, Aug 4, 2016 at 5:05 PM, Cantor, Scott <[email-masked]> wrote:

> I trust it's understood that at a large organization, there is no way to
> assume any relationship whatsoever between one.osu.edu and two.osu.edu.
> Different software, departments, operating policies, everything. They may
> as well not be related.
>
> This spec doesn't assume that a binding to one is equivalent to the other,
> does it? That would be...really unfortunate.
>
> -- Scott
>
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 5 Aug 2016 00:34:22 +0000

> (section 2.1). This means that if one.osu.edu <http://one.osu.edu>  and
> two.osu.edu <http://two.osu.edu>  support the same key params, a client
> will use the same token binding key with both. This is required so that token
> binding keys are scoped at the same level as cookies.

Key params meaning the actual key? According to the draft, I thought it referred to the type of algorithm being applied, which is a very limited set, and certainly doesn't imply any relationship between the servers.

> The two domains are free to negotiate different key params if they want.

Maybe I don't understand what key params means. I'm not that familiar with the material yet, but it's deeply worrying to see people refer to eTLD+1 as a security umbrella.

> The concern around H2 coalescing only applies if the two domain names
> point to the same IP address and the certificate lists both domain names in
> the SAN. If those conditions are met, I think it's reasonable to assume that

Yes, I agree wth that.

-- Scott

---

From: Nick Harper <[email-masked]>
Date: Thu, 4 Aug 2016 17:39:56 -0700

On Thu, Aug 4, 2016 at 5:34 PM, Cantor, Scott <[email-masked]> wrote:

> Key params meaning the actual key? According to the draft, I thought it
> referred to the type of algorithm being applied, which is a very limited
> set, and certainly doesn't imply any relationship between the servers.
>

Key params means the type of key (e.g. RSA-PSS or ECDSA P256). The keys
themselves are scoped to eTLD+1 - see draft-ietf-tokbind-https-05 section
2.1 for the wording. Suppose we have a client that only supports P256 keys
(e.g. Chrome). If this client negotiates token binding with both one.osu.edu
and two.osu.edu, then it will use the same key for both, because the key is
scoped to osu.edu. This is the same as with cookies: a client could connect
to one.osu.edu which sets a cookie on the domain osu.edu, and on a future
connection to two.osu.edu, that server can read the cookie that one.osu.edu
set.

> Maybe I don't understand what key params means. I'm not that familiar with
> the material yet, but it's deeply worrying to see people refer to eTLD+1 as
> a security umbrella.
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 5 Aug 2016 00:47:19 +0000

> Key params means the type of key (e.g. RSA-PSS or ECDSA P256).

Yes, that was my understanding (thanks).

> The keys
> <http://one.osu.edu>  and two.osu.edu <http://two.osu.edu> , then it will
> use the same key for both, because the key is scoped to osu.edu
> <http://osu.edu> . This is the same as with cookies: a client could connect to
> one.osu.edu <http://one.osu.edu>  which sets a cookie on the domain
> osu.edu <http://osu.edu> , and on a future connection to two.osu.edu
> <http://two.osu.edu> , that server can read the cookie that one.osu.edu
> <http://one.osu.edu>  set.

*Could* set a cookie that way, yes. My question is why it must, since servers certainly can and do set cookies directly on the full hostname. That's a far more common case.

-- Scott

---

From: Nick Harper <[email-masked]>
Date: Thu, 4 Aug 2016 17:52:46 -0700

A site example.com might want to issue a cookie on that domain and create a
token binding for it. It then might use that cookie on one.example.com and
two.example.com. To be able to verify the token binding, the client has to
use the same key on the connection to example.com, one.example.com, and
two.example.com. The client doesn't know a priori how the server might
choose to issue and use cookies across its domains, so it scopes the key to
match the widest scope of the cookies to ensure that the server can verify
the binding regardless of where the server uses the cookies.

On Thu, Aug 4, 2016 at 5:47 PM, Cantor, Scott <[email-masked]> wrote:

>
> *Could* set a cookie that way, yes. My question is why it must, since
> servers certainly can and do set cookies directly on the full hostname.
> That's a far more common case.
>
> -- Scott
>
>

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2016 21:00:02 -0400

Token binding dosent change the way hosts set cookies from a scoping perspective.

However if one.osu.edu set a domain cookie for osu.edu that contains the token binding ID  then two.osu.edu would be able to validate that cookie as it would be receiving the same token binding ID from the user agent (assuming that the same keyparam was negotiated).

Think of eTLD+1 as the segmentation boundary for correlation.    

If the browser used the same token binding ID for every site then they would be able to easily correlate the browsers activity.

So if there is a problem with eTLD+1 it is that token binding could be used as a way to correlate the users activity between one.osu.edu and two.osu.edu.

However given that the cookie policy of browsers is going to let you do that anyway token binding is not leaking any more information than the cookies would on there own.

The idea is that in situations where hosts do share cookie information they can also share the token binding ID so that those cookies are bound to the user agent and not subject to man in the middle theft and replay.

I hope that helps.

John B.

> On Aug 4, 2016, at 8:47 PM, Cantor, Scott <[email-masked]> wrote:
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 5 Aug 2016 01:20:39 +0000

> The idea is that in situations where hosts do share cookie information they
> can also share the token binding ID so that those cookies are bound to the
> user agent and not subject to man in the middle theft and replay.

The confusion was mine, my brain was seeing "token binding key" and thinking "token binding header". The signature, not the private key in the client. Sorry for the interruption...

-- Scott

---

From: "Manger, James" <[email-masked]>
Date: Fri, 5 Aug 2016 12:42:03 +1000

> Token binding dosent change the way hosts set cookies from a scoping perspective.

Yes it does, because asking for token binding is effectively establishing a randomly-chosen long-term "cookie" ... that happens to have crypto protection, and is transported in a different field than the "Cookie" header.

> The idea is that in situations where hosts do share cookie information they can also share the token binding ID so that those cookies are bound to the user agent and not subject to man in the middl…

Hosts one.osu.edu and two.osu.edu can choose to share cookies, but they can also choose not to.
How bad is it if token binding doesn't allow that choice (it is always shared)?
You cannot get the security benefit of token binding without allowing correlation across eTLD+1. You cannot "clear cookies" for one.osu.edu without harming your security at two.osu.edu.

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?

--
James Manger

---

From: Brian Campbell <[email-masked]>
Date: Fri, 5 Aug 2016 10:51:27 -0600

On Thu, Aug 4, 2016 at 5:53 PM, Subodh Iyengar <[email-masked]> wrote:

> The Http2 spec allows this connection coalescing to happen. You can run 2
> different origins on the same IP address. Servers already use SNI
> information to determine which certificate to serve, similarly servers
> could also use this to determine what token binding params could be
> negotiated. I'm definitely not endorsing this behavior :), but that it's
> possible.
>
>
I tend to agree with Nick (and I guess you too given the non-endorsement :)
that it seems like a reasonable assumption/expectation that the supported
token binding key parameters would be the same in that situation. There's
good reason to use SNI to chose the server certificate.  Using SNI to vary
TB params seems just arbitrary. I think that's an acceptable limitation.

> advice would go a long way to prevent silly mistakes from service owners. This
> section could possibly say that you should use the same token bindings for
> all domains within the eTLD + 1.
>

There are many cases where, due to different products or technology stacks
or ownership or etc., that may not be feasible.  Any such guidance just
needs to be aware of real world deployment constraints.

>  It could also include guidance on migrating token binding params as well
> which we're discussing on another thread.
>
> Subodh
> *From:* Nick Harper [[email-masked]]
> *Sent:* Thursday, August 04, 2016 3:49 PM
> *To:* Brian Campbell
> *Cc:* Subodh Iyengar; IETF Tokbind WG
> *Subject:* Re: [Unbearable] support for different key parameters within
> the same TLD+1
>
> covers multiple domains (e.g. one.example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__one.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=Xz0qySs-UD_mfh0z8Y4P0X-23AGDMCfXabDRKhCO4yI&e=>
> and two.example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__two.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=drxkM18T-I8dsXPCyuEHY6ykK_AaBn-Ej6SpUEZMOvU&e=>),
> then an H2 client can coalesce connections for one.example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__one.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=Xz0qySs-UD_mfh0z8Y4P0X-23AGDMCfXabDRKhCO4yI&e=>
> and two.example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__two.example.com&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=drxkM18T-I8dsXPCyuEHY6ykK_AaBn-Ej6SpUEZMOvU&e=>
> On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell <[email-masked]
> > wrote:
>
>> https://www.ietf.org/mailman/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=LkbmWhNTDGLIMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=xJqwvIqcoVDiM2tkLv66sXkZtUzI6z7PVT5_vdvOwqg&e=>
>> listinfo/unbearable
>>
>>
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 5 Aug 2016 11:26:16 -0600

> cookies. The two domains are free to negotiate different key params if they

The expected client behavior in that last case is what my question was
about originally. Even though token binding keys are scoped at eTLD+1,
because two sub domains can negotiate different key params, there seems to
be an implication that a client should be able to store a key per supported
key params per eTLD+1. This wasn't immediately obvious, to me anyway, so
some additional guidance seems like it might be valuable.

> the SAN. If those conditions are met, I think it's reasonable to assume
> that there's a relationship between them, and require the two domains to

Agree.

>> This spec doesn't assume that a binding to one is equivalent to the
>> other, does it? That would be...really unfortunate.
>>
>> -- Scott
>>
>>
>