Subject: [Unbearable] reviewing our 00's

From: Leif Johansson <[email-masked]>
Date: Sat, 18 Apr 2015 15:33:16 +0200

Folks,

The core drafts have been out and published as WG documents for a couple
of weeks now. Please review!

	Cheers Leif

---

From: [email-masked]
Date: Sat, 18 Apr 2015 17:16:15 +0200

Sorry,

but like a lot of people we are all busy,

can you repeat the links,

without wishing to sound like Dr Who, you catch me at a time when I have time,

possibly its the same for others, quick links without having to mine them would be most useful brigadier :-)

best

Dean

Gesendet: Samstag, 18. April 2015 um 15:33 Uhr

Von: "Leif Johansson" <[email-masked]>

An: "[email-masked]" <[email-masked]>

Betreff: [Unbearable] reviewing our 00's

Folks,

Cheers Leif

_______________________________________________

Unbearable mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/unbearable

---

From: Brian Campbell <[email-masked]>
Date: Sat, 18 Apr 2015 09:21:44 -0600

Some links:

http://tools.ietf.org/html/draft-ietf-tokbind-protocol-00
http://tools.ietf.org/html/draft-ietf-tokbind-https-00

https://github.com/TokenBinding/

On Sat, Apr 18, 2015 at 9:16 AM, <[email-masked]> wrote:

>  *Gesendet:* Samstag, 18. April 2015 um 15:33 Uhr
> *Von:* "Leif Johansson" <[email-masked]>
> *An:* "[email-masked]" <[email-masked]>
> *Betreff:* [Unbearable] reviewing our 00's
>
> Folks,
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 18 Apr 2015 19:57:51 +0300

> of weeks now. Please review!

Some points:

1) ALPN does not scale. Sadly, HTTP/2 has no way to perform server 
0RTT capability advertisment without TLS 1.3 (and even there,
it might not work with client certs) otherwise.

2) Following CFRG on signatures would be useful. They have
completed ECDH work and moved to signatures (which shouldn't
take too long to complete).

3) I expect somebody to complain about inventing a new key/
signature format instead of using existing ones (e.g. JOSE
or whatever TLS RPK uses). :-)

4) TLS-unique can't be synchronized without resumption (or
insecure renegotiation), even without EMS.

5) If one does not have HSM available, one should handle the
keys in dedicated process. Makes grabbing those keys more
annoying, to the point when the attacker can grab those,
you are likely toast anyway.

6) Why is referred binding restricted to 301 and 302? I can't
come up with a sensible category that only has 301 and 302.

-Ilari

---

From: [email-masked]
Date: Sat, 18 Apr 2015 20:23:15 +0200

Dear all,

nit:

"The Token Binding protocol allows client/server applications to create long-lived,"

just a semantic point but this is not yet proven so

"The Token Binding protocol aims to allow client/server applications to create long-lived" is better.

purly semantic

"The idea of Token Binding is to prevent such attacks by cryptographically binding security tokens to the TLS layer."

shoud be

"The idea of Token Binding is to prevent such attacks by cryptographically binding security tokens at the TLS layer."

Introduction:

"Token Binding identifiers are never transmitted in clear text and can be reset by the user at any time, e.g. when clearing browser cookies."

This sounds alarmist to most readers, meaning this should not be stated without further explanation, but the introduction is not the right place, so defer this until later.

2. Token Binding Protocol Overview

"This message is only sent if the client and server agree on the use of the Token Binding protocol."

Be specific on what happens when they do not agree. This is detailed later, but a re-wright for clarity would be benificial.

"If the bound token came from a TLS connection without a Token Binding, or if the IDs don't match, the token is discarded."

should be appended ".. and the connection dropped." This is stated later, but to avoid confusion it should also be mentioned briefly at this point.

Dean

Gesendet: Samstag, 18. April 2015 um 17:21 Uhr

Von: "Brian Campbell" <[email-masked]>

An: [email-masked]

Cc: "[email-masked]" <[email-masked]>

Betreff: Re: [Unbearable] reviewing our 00's

Some links:

Sorry,

best

Dean

Folks,

Cheers Leif

Unbearable mailing list

[email-masked]

Unbearable mailing list

[email-masked]

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

---

From: [email-masked]
Date: Sat, 18 Apr 2015 22:11:13 +0200

Dear All,

perhaps its a bit late to be raising this point but:

Abstract:

"an HTTP server issues a security token (such as a cookie) to a client, and expects the client to send the security token back to the server at a later time in order to authenticate."

What happens if exactly at that moment the the client clears thier cache after the token/cookie is received?

Something in the challenge-response mechanism is missing here. Why does the HTTP Server issue the token, at this point there is no mention of a challenge prompting this response. What should the challenge look like? Basically this does not belong in the abstract.

"Binding the token to the TLS connection between client and server protects the security token from theft, and ensures that the security token can only be used by the client that it was issued to."

This binding is not yet established, so ... "and would ensure that the security token..."

Please, I may have misunderstood something, but are we saying that a token issued by server A to client X may possibly be accepted by server B, surely this can only be the case on implicit trust between servers A and B?

Further, "the client proves possession of (private key) to the server, and is long-lived (i.e., subsequent TLS connections between the same client and server have the same Token Binding ID."

I still have the same conceptual problem with cache flushing, if the cookie is gone the whole process has to start from the beginning and the client has to prove they are still the same client. In other words re-establish the 3rd leg of a challenge response protocol. Where this is still the same client only time is lost. but I am afraid that should an attacker be able to generate such a failure they may be able to hijack the session.

Section 3.1 suggests that each client operate a large scale Key-management system, "clients use different private keys to establish Provided Token Binding IDs with different servers".

Clients are clients and this should not be thier business.

It was with this, to my mind, major architectural conceptual misdiection that stoped my reading further.

Salutem

Dean

An: [email-masked]

Some links:

Sorry,

best

Dean

Folks,

Cheers Leif

Unbearable mailing list

[email-masked]

Unbearable mailing list

[email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Apr 2015 11:19:06 -0600

Not sure if this list or the github issue tracker is the right place for
review feedback so I'm gonna go with a bit of a hybrid model by sending
this link https://github.com/TokenBinding/Internet-Drafts/issues/10 to this
list.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 20 Apr 2015 19:21:45 +0200

issues on github, discussions of those issues here!

> 20 apr 2015 kl. 19:19 skrev Brian Campbell <[email-masked]>:
> 
> Not sure if this list or the github issue tracker is the right place for review feedback so I'm gonna go with a bit of a hybrid model by sending this link https://github.com/TokenBinding/Internet-Drafts/issues/10 to this list. 
> 
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 Apr 2015 11:09:59 -0700

> of weeks now. Please review!

I think that this should be one spec:

https://github.com/TokenBinding/Internet-Drafts/issues/11

I think that this should not use ALPN:

https://github.com/TokenBinding/Internet-Drafts/issues/3

And though I still prefer it if everything were native to HTTP, I
believe that Dirk and Andrei believe the performance characteristics
of such a solution to be disastrously bad.  An TLS extension does at
least solve that problem, even if it is architecturally distasteful:

https://github.com/TokenBinding/Internet-Drafts/issues/4

No doubt there will be more once those have been sorted out, but
that's probably more than enough for now.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 20 Apr 2015 21:54:55 +0000

Hi Ilari,

1) Agreement has been reached in Dallas that we will define a new TLS extension to negotiate Token Binding key parameters, instead of using ALPN. I hope to publish a new I-D for the TLS extension, and update  draft-ietf-tokbind-protocol in the next 2-3 weeks.

2) We should certainly consider CFRG recommendation, once it's available.

3) The intent was to make this as straightforward as possible, and to reuse TLS registries and structures.

4) But resumption and renegotiation do exist.

5) There are several ways to protect keys in SW; I'd rather not prescribe one of the possible solutions.

6) I believe this is because 301 and 302 are common ways to perform URL redirection, but Dirk may have a better justification.

Thanks,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Saturday, April 18, 2015 9:58 AM
To: Leif Johansson
Cc: [email-masked]
Subject: Re: [Unbearable] reviewing our 00's

On Sat, Apr 18, 2015 at 03:33:16PM +0200, Leif Johansson wrote:
> 
> Folks,
> 
> The core drafts have been out and published as WG documents for a 
> couple of weeks now. Please review!

Some points:

1) ALPN does not scale. Sadly, HTTP/2 has no way to perform server 0RTT capability advertisment without TLS 1.3 (and even there, it might not work with client certs) otherwise.

2) Following CFRG on signatures would be useful. They have completed ECDH work and moved to signatures (which shouldn't take too long to complete).

3) I expect somebody to complain about inventing a new key/ signature format instead of using existing ones (e.g. JOSE or whatever TLS RPK uses). :-)

4) TLS-unique can't be synchronized without resumption (or insecure renegotiation), even without EMS.

5) If one does not have HSM available, one should handle the keys in dedicated process. Makes grabbing those keys more annoying, to the point when the attacker can grab those, you are likely toast anyway.

6) Why is referred binding restricted to 301 and 302? I can't come up with a sensible category that only has 301 and 302.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Mon, 20 Apr 2015 22:03:28 +0000

Hi Dean,

Thanks for the editorial comments; will rephrase in the next revision.

Ø  What happens if exactly at that moment the the client clears thier cache after the token/cookie is received?

Ø  I still have the same conceptual problem with cache flushing, if the cookie is gone the whole process has to start from the beginning and the client has to prove they are still the same client. In other words re-establish the 3rd leg of a challenge response protocol.
If the cookie is gone, the server will have to authenticate this client again. This is the case today; I don’t think Token Binding is changing anything WRT this case.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, April 18, 2015 1:11 PM
Cc: [email-masked]
Subject: Re: [Unbearable] reviewing our 00's

Dear All,

Salutem
Dean

Gesendet: Samstag, 18. April 2015 um 17:21 Uhr
Von: "Brian Campbell" <[email-masked]<mailto:[email-masked]>>
An: [email-masked]<mailto:[email-masked]>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [Unbearable] reviewing our 00's
Some links:

best
Dean

Folks,

Cheers Leif

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

---

From: Andrei Popov <[email-masked]>
Date: Mon, 20 Apr 2015 22:35:03 +0000

> I think that this should be one spec:
It is very likely that we'll want to use Token Binding with protocols other than HTTPS. Token Binding protocol message formats, key parameter negotiation, etc. are likely to be the same regardless of the application protocol, but the encapsulation of Token Binding messages in the application protocol will look different in each application protocol.

This is why I believe that keeping Token Binding protocol basics in a separate I-D is beneficial. In terms of presentation, we can certainly make improvements so that the two documents are more readable.

> I think that this should not use ALPN:
Yes, we've agreed on this in Dallas; I'll publish a new I-D for the TLS extension, and update  draft-ietf-tokbind-protocol in the next 2-3 weeks.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Monday, April 20, 2015 11:10 AM
To: Leif Johansson
Cc: [email-masked]
Subject: Re: [Unbearable] reviewing our 00's

And though I still prefer it if everything were native to HTTP, I believe that Dirk and Andrei believe the performance characteristics of such a solution to be disastrously bad.  An TLS extension does at least solve that problem, even if it is architecturally distasteful:

No doubt there will be more once those have been sorted out, but that's probably more than enough for now.

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 20 Apr 2015 15:47:55 -0700

On Mon, Apr 20, 2015 at 2:54 PM, Andrei Popov <[email-masked]>
wrote:

> 1) Agreement has been reached in Dallas that we will define a new TLS
> extension to negotiate Token Binding key parameters, instead of using ALPN.
> I hope to publish a new I-D for the TLS extension, and update
> draft-ietf-tokbind-protocol in the next 2-3 weeks.

This is sounding better already...

-- 
Tony Arcieri

---

From: Leif Johansson <[email-masked]>
Date: Tue, 21 Apr 2015 08:55:43 +0200

> 1) Agreement has been reached in Dallas that we will define a new TLS extension to negotiate Token Binding key parameters, instead of using ALPN. I hope to publish a new I-D for the TLS extension,…

Why don't you make a note in the appropriate issue to this fact so we
don't have to revisit.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 21 Apr 2015 16:46:30 +0000

Done. I've also added issue 12, based on implementation experience:

Token Binding ID includes tokenbinding_type field to indicate whether this is a Provided or Referred binding.

In the federation scenario, the client proves possession of the same Krp to the RP (as Provided binding) and to the IDP (as Referred binding). If the IDP includes the Referred Token Binding ID in the token, the RP cannot directly compare it with the Provided Token Binding ID established with the client, because the first byte of the ID (tokenbinding_type) will be different.

We should provide guidance on this in draft-ietf-tokbind-https to avoid confusion. The easiest thing to do is probably to exclude tokenbinding_type when comparing Token Binding IDs.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Monday, April 20, 2015 11:56 PM
To: [email-masked]
Subject: Re: [Unbearable] reviewing our 00's

> 1) Agreement has been reached in Dallas that we will define a new TLS extension to negotiate Token Binding key parameters, instead of using ALPN. I hope to publish a new I-D for the TLS extension,…

Why don't you make a note in the appropriate issue to this fact so we don't have to revisit.

---

From: [email-masked]
Date: Wed, 22 Apr 2015 16:14:11 +0200

Hi Andrea,

yes, quite right, and of course if they perviously had the relevant cookie, resetablishing it is trivial. And someone not accepting cookies on principle would not have been authenticated in the first place. Bu this is more or less what I wrote previously. Which mechanism are we relying on to prevent hyjacking the returned cookie?

But I was more concerned with the key-management client-side issue. I have no proposed solution up my sleave, but it concerns me that like many others very often I am in hundreds of web-sites per day.

Added to this during any particular day I am using a Win-8 desktop, a Win-7 laptop, and an Android based Tablet. I am just thinking that scaleability should be built into solutions at an early stage.

best,

Dean

Gesendet: Dienstag, 21. April 2015 um 00:03 Uhr

Von: "Andrei Popov" <[email-masked]>

An: "[email-masked]" <[email-masked]>

Hi Dean,

Cheers,

Andrei

Cc: [email-masked]

Dear All,

Abstract:

Salutem

Dean

An: [email-masked]

Some links:

Sorry,

best

Dean

Folks,

Cheers Leif

Unbearable mailing list

[email-masked]

Unbearable mailing list

[email-masked]

---

From: Andrei Popov <[email-masked]>
Date: Wed, 22 Apr 2015 17:29:30 +0000

Ø  Which mechanism are we relying on to prevent hyjacking the returned cookie?
Are you talking about a scenario where the client deletes cookies (and token bindings), re-authenticates with the web site, and receives a new cookie? In this case, the new cookie will be bound to the new Token Binding Key (assuming the client and server have negotiated the use of Token Binding).

Ø  But I was more concerned with the key-management client-side issue.

Ø  I am just thinking that scaleability should be built into solutions at an early stage.
If the client can manage cookies in a scalable manner, this client can probably be enhanced to also manage Token Binding keys in a scalable manner. Can you elaborate on the specific client-side scalability concerns?

Cheers,

Andrei

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 22, 2015 7:14 AM
To: Andrei Popov
Cc: [email-masked]
Subject: Aw: Re: [Unbearable] reviewing our 00's

Hi Andrea,

best,
Dean

Gesendet: Dienstag, 21. April 2015 um 00:03 Uhr
Von: "Andrei Popov" <[email-masked]<mailto:[email-masked]>>
An: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [Unbearable] reviewing our 00's
Hi Dean,

>  I still have the same conceptual problem with cache flushing, if the cookie is gone the whole process has to start from the beginning and the client has to prove they are still the same client. In other words re-establish the 3rd leg of a challenge response protocol.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Saturday, April 18, 2015 1:11 PM
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Unbearable] reviewing our 00's

Dear All,

Salutem
Dean

On Sat, Apr 18, 2015 at 9:16 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Sorry,

best
Dean
Gesendet: Samstag, 18. April 2015 um 15:33 Uhr
Von: "Leif Johansson" <[email-masked]<mailto:[email-masked]>>
An: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Betreff: [Unbearable] reviewing our 00's

Folks,

Cheers Leif

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

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

---

From: [email-masked]
Date: Thu, 23 Apr 2015 23:13:01 +0200

I just found a presentation of yours written together with Vinod "The Token Binding Protocol." This is most useful.

"In this case, the new cookie will be bound to the new Token Binding Key (assuming the client and server have negotiated the use of Token Binding)."

This is now diagressing too far, but what I meant was that TLS relying on certs in a controlled environment may be fine, but I am not so happy about it in the wilder Internet. But I think I have answered my own question, which was that combining this with say HIP would not get us any further.

"Can you elaborate on the specific client-side scalability concerns?"

Sorry, no, no experimental data to share, just general concern. By scalability I dont just mean the volume of cookies on any one client machine, but also from home I use three different machines. different OS's, different browsers or versions, and add to that at work and at clients. I would like the servers I visit all to securely recognise me as the same person. Perhaps this was already addressed and I missed it.

all the best

Dean

Gesendet: Mittwoch, 22. April 2015 um 19:29 Uhr

Cheers,

Andrei

To: Andrei Popov

Cc: [email-masked]

Hi Andrea,

best,

Dean

Hi Dean,

Cheers,

Andrei

Cc: [email-masked]

Dear All,

Abstract:

Salutem

Dean

An: [email-masked]

Some links:

Sorry,

best

Dean

Folks,

Cheers Leif

Unbearable mailing list

[email-masked]

Unbearable mailing list

[email-masked]

---

From: Bill Mills <[email-masked]>
Date: Thu, 23 Apr 2015 21:20:49 +0000 (UTC)

"Sorry, no, no experimental data to share, just general concern. By scalability I dont just mean the volume of cookies on any one client machine, but also from home I use three different machines. different OS's, different browsers or versions, and add to that at work and at clients. I would like the servers I visit all to securely recognise me as the same person. Perhaps this was already addressed and I missed it." That's outside the scope, this isn't shared state/authentication across N browsers/devices.  That is possible, but it would require an SSO solution on the device/box that allows sharing of secrets and credentials across apps each of which could then use a bound token per these specs. 

     On Thursday, April 23, 2015 2:13 PM, "[email-masked]" <[email-masked]> wrote:

 I just found a presentation of yours written together with Vinod "The Token Binding Protocol." This is most useful. "In this case, the new cookie will be bound to the new Token Binding Key (assuming the client and server have negotiated the use of Token Binding)." This is now diagressing too far, but what I meant was that TLS relying on certs in a controlled environment may be fine, but I am not so happy about it in the wilder Internet. But I think I have answered my own question, which was that combining this with say HIP would not get us any further. "Can you elaborate on the specific client-side scalability concerns?" Sorry, no, no experimental data to share, just general concern. By scalability I dont just mean the volume of cookies on any one client machine, but also from home I use three different machines. different OS's, different browsers or versions, and add to that at work and at clients. I would like the servers I visit all to securely recognise me as the same person. Perhaps this was already addressed and I missed it. all the bestDean Gesendet: Mittwoch, 22. April 2015 um 19:29 Uhr
Von: "Andrei Popov" <[email-masked]>
An: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Betreff: Re: [Unbearable] reviewing our 00'sØ  Which mechanism are we relying on to prevent hyjacking the returned cookie? Are you talking about a scenario where the client deletes cookies (and token bindings), re-authenticates with the web site, and receives a new cookie? In this case, the new cookie will be bound to the new Token Binding Key (assuming the client and server have negotiated the use of Token Binding).Ø  But I was more concerned with the key-management client-side issue.Ø  I am just thinking that scaleability should be built into solutions at an early stage.If the client can manage cookies in a scalable manner, this client can probably be enhanced to also manage Token Binding keys in a scalable manner. Can you elaborate on the specific client-side scalability concerns? Cheers, Andrei From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 22, 2015 7:14 AM
To: Andrei Popov
Cc: [email-masked]
Subject: Aw: Re: [Unbearable] reviewing our 00's Hi Andrea, yes, quite right, and of course if they perviously had the relevant cookie, resetablishing it is trivial. And someone not accepting cookies on principle would not have been authenticated in the first place. Bu this is more or less what I wrote previously. Which mechanism are we relying on to prevent hyjacking the returned cookie?  But I was more concerned with the key-management client-side issue. I have no proposed solution up my sleave, but it concerns me that like many others very often I am in hundreds of web-sites per day.Added to this during any particular day I am using a Win-8 desktop, a Win-7 laptop, and an Android based Tablet. I am just thinking that scaleability should be built into solutions at an early stage. best,Dean    Gesendet: Dienstag, 21. April 2015 um 00:03 Uhr
Von: "Andrei Popov" <[email-masked]>
An: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Betreff: Re: [Unbearable] reviewing our 00'sHi Dean, Thanks for the editorial comments; will rephrase in the next revision. Ø  What happens if exactly at that moment the the client clears thier cache after the token/cookie is received?Ø  I still have the same conceptual problem with cache flushing, if the cookie is gone the whole process has to start from the beginning and the client has to prove they are still the same client. In other words re-establish the 3rd leg of a challenge response protocol.If the cookie is gone, the server will have to authenticate this client again. This is the case today; I don’t think Token Binding is changing anything WRT this case. Cheers, Andrei From: Unbearable [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, April 18, 2015 1:11 PM
Cc: [email-masked]
Subject: Re: [Unbearable] reviewing our 00's Dear All, http://tools.ietf.org/html/draft-ietf-tokbind-https-00 perhaps its a bit late to be raising this point but:Abstract:"an HTTP server issues a security token (such as a cookie) to a client, and expects the client to send the security token back to the server at a later time in order to authenticate." What happens if exactly at that moment the the client clears thier cache after the token/cookie is received?Something in the challenge-response mechanism is missing here. Why does the HTTP Server issue the token, at this point there is no mention of a challenge prompting this response. What should the challenge look like? Basically this does not belong in the abstract. "Binding the token to the TLS connection between client and server protects the security token from theft, and ensures that the security token can only be used by the client that it was issued to."This binding is not yet established, so ... "and would ensure that the security token..." Please, I may have misunderstood something, but are we saying that a token issued by server A to client X may possibly be accepted by server B, surely this can only be the case on implicit trust between servers A and B?Further, "the client proves possession of (private key) to the server, and is long-lived (i.e., subsequent TLS connections between the same client and server have the same Token Binding ID."I still have the same conceptual problem with cache flushing, if the cookie is gone the whole process has to start from the beginning and the client has to prove they are still the same client. In other words re-establish the 3rd leg of a challenge response protocol. Where this is still the same client only time is lost. but I am afraid that should an attacker be able to generate such a failure they may be able to hijack the session. Section 3.1 suggests that each client operate a large scale Key-management system, "clients use different private keys to establish Provided Token Binding IDs with different servers".Clients are clients and this should not be thier business.It was with this, to my mind, major architectural conceptual misdiection that stoped my reading further. SalutemDean Gesendet: Samstag, 18. April 2015 um 17:21 Uhr
Von: "Brian Campbell" <[email-masked]>
An: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Betreff: Re: [Unbearable] reviewing our 00'sSome links:

https://github.com/TokenBinding/  On Sat, Apr 18, 2015 at 9:16 AM, <[email-masked]> wrote: 
Sorry, but like a lot of people we are all busy, can you repeat the links,without wishing to sound like Dr Who, you catch me at a time when I have time,possibly its the same for others, quick links without having to mine them would be most useful brigadier :-) bestDeanGesendet: Samstag, 18. April 2015 um 15:33 Uhr
Von: "Leif Johansson" <[email-masked]>
An: "[email-masked]" <[email-masked]>
Betreff: [Unbearable] reviewing our 00's
Folks,

Cheers Leif

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

---

From: Andrei Popov <[email-masked]>
Date: Thu, 23 Apr 2015 22:55:13 +0000

Ø  By scalability I dont just mean the volume of cookies on any one client machine, but also from home I use three different machines. different OS's, different browsers or versions, and add to that at work and at clients. I would like the servers I visit all to securely recognise me as the same person. Perhaps this was already addressed and I missed it.
Yes, it is true that by design Token Binding prevents any cookie “roaming” or cookie jar synchronization between machines.

Cheers,

Andrei

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 23, 2015 2:13 PM
To: Andrei Popov
Cc: [email-masked]
Subject: Aw: Re: [Unbearable] reviewing our 00's

all the best
Dean

>  Which mechanism are we relying on to prevent hyjacking the returned cookie?

>  But I was more concerned with the key-management client-side issue.

>  I am just thinking that scaleability should be built into solutions at an early stage.

Cheers,

Andrei

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, April 22, 2015 7:14 AM
To: Andrei Popov
Cc: [email-masked]<mailto:[email-masked]>
Subject: Aw: Re: [Unbearable] reviewing our 00's

Hi Andrea,

best,
Dean

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]<[email-masked]>] On Behalf Of [email-masked]
Sent: Saturday, April 18, 2015 1:11 PM
Cc: [email-masked]
Subject: Re: [Unbearable] reviewing our 00's

Dear All,

Salutem
Dean

best
Dean

Folks,

Cheers Leif