Subject: [TLS] The alternative idea I had for token buckets.

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 28 Mar 2017 15:21:53 +0000

Here's how it would work:

-          The server has a long term secret key K, which it never gives out

-          When the server wants to give a token to a client, it picks a random value R, and securely gives the client the values R and E_K(R)

-          When the client wants to use the token, it picks a value i, and computes the key Hash( R || i).  It uses that key to protect the message, and also sends the server the values E(R) and i

-          The server decrypts the value E(R) to recover R, it computes Hash( R || i) to recover the message key, and then decrypts the message

That way, the server doesn't have to send the client N different tokens...

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Mar 2017 10:36:31 -0500

I'm sorry, but I don't understand this proposal.  I'm losing you when
you say E(R) without specifying the key that you are using.

On 28 March 2017 at 10:21, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> Here’s how it would work:
>
>
>
> -          When the server wants to give a token to a client, it picks a
> random value R, and securely gives the client the values R and E_K(R)
>
> -          When the client wants to use the token, it picks a value i, and
> computes the key Hash( R || i).  It uses that key to protect the message,
> and also sends the server the values E(R) and i
>
> -          The server decrypts the value E(R) to recover R, it computes
> Hash( R || i) to recover the message key, and then decrypts the message
>
>
>
> That way, the server doesn’t have to send the client N different tokens…
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 28 Mar 2017 15:41:28 +0000

E_K(R); that is, R is encrypted with the server's long term key.

(I meant to specify that...)

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Tuesday, March 28, 2017 11:37 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: <[email-masked]>
> Subject: Re: [TLS] The alternative idea I had for token buckets.
> 
> I'm sorry, but I don't understand this proposal.  I'm losing you when you say
> E(R) without specifying the key that you are using.
> 
> > computes the key Hash( R || i).  It uses that key to protect the
> > message, and also sends the server the values E(R) and i
> >

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Mar 2017 10:46:14 -0500

> (I meant to specify that...)

OK, so how does the server recover E_K(R)?  The point here is that it
doesn't know R.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 28 Mar 2017 15:48:55 +0000

> Sent: Tuesday, March 28, 2017 11:46 AM
> OK, so how does the server recover E_K(R)?  The point here is that it doesn't
> know R.

The server recovers E_K(R) because the client sent it (along with i and the protected message).  It recovers R because it also knows K.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Mar 2017 10:51:01 -0500

> The server recovers E_K(R) because the client sent it (along with i and the protected message).  It recovers R because it also knows K.

So E_K(R) is sent directly?  That would link packets.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 28 Mar 2017 15:57:01 +0000

Sorry, I wasn't aware that unlinkability was a requirement...

> Sent: Tuesday, March 28, 2017 11:51 AM
> > The server recovers E_K(R) because the client sent it (along with i and the
> protected message).  It recovers R because it also knows K.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Mar 2017 11:18:02 -0500

> Sorry, I wasn't aware that unlinkability was a requirement...

Yeah, it's the only hard requirement. :)