Subject: [Unbearable] What is the right action on TLS session resumption?

From: Bill Cox <[email-masked]>
Date: Tue, 1 Sep 2015 18:58:49 -0700

I may have missed it in the specs, but I do not recall seeing any
discussion of what to do on a session resumption.  The TLS Token Binding
extension is negotiated on the initial handshake.  On resumption, the
client I believe needs to send the Token Binding extension in case the
server rejects the resumption and falls back to a full handshake.

Should the server re-send the Token Binding extension after resuming a
session?

I currently do, but I can see arguments for both ways.  The main point in
re-sending the extension is to inform the client that the server it's
talking to does support Token Binding.  There may be rare cases where a
session is resumed by a server that does not support Token Binding, and not
sending the Token Binding extension seems like a natural way to indicate
this.  On the other hand, this case is rare and the application layer in
the client could be expected to remember the key parameters initially
negotiated.  If so, should the client ignore the Token Binding key
parameters negotiated on resumption, or switch to the new parameters in
case they change?

Thanks,
Bill

---

From: Andrei Popov <[email-masked]>
Date: Wed, 2 Sep 2015 02:31:49 +0000

Hi Bill,

Currently, TBNEGO spec says:
“If the "token_binding" extension is included in the server hello and
   the TLS handshake succeeds, it means that the Token Binding protocol
   version and key parameters have been negotiated between the client
   and the server and SHALL be definitive for the TLS session.”

Once TB parameters have been negotiated for a TLS session, they apply to all connections within that TLS session. There is no need to resend the extension on resumption. The application of course needs to send the Token Binding messages in every connection within such TLS session.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Tuesday, September 1, 2015 6:59 PM
To: [email-masked]
Subject: [Unbearable] What is the right action on TLS session resumption?

I may have missed it in the specs, but I do not recall seeing any discussion of what to do on a session resumption.  The TLS Token Binding extension is negotiated on the initial handshake.  On resumption, the client I believe needs to send the Token Binding extension in case the server rejects the resumption and falls back to a full handshake.

Should the server re-send the Token Binding extension after resuming a session?

I currently do, but I can see arguments for both ways.  The main point in re-sending the extension is to inform the client that the server it's talking to does support Token Binding.  There may be rare cases where a session is resumed by a server that does not support Token Binding, and not sending the Token Binding extension seems like a natural way to indicate this.  On the other hand, this case is rare and the application layer in the client could be expected to remember the key parameters initially negotiated.  If so, should the client ignore the Token Binding key parameters negotiated on resumption, or switch to the new parameters in case they change?

Thanks,
Bill

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 02 Sep 2015 17:31:30 +0000

Interesting. From the original ChannelID draft
<https://tools.ietf.org/html/draft-balfanz-tls-channelid-01#section-5>:

"Unlike many other TLS extensions, this extension does not establish
properties of the session, only of the connection."

The reason we had decided to do it that way was the following: In the
future, I imagined that ChannelID (i.e., TokenBinding) private keys would
reside in protected hardware, but I didn't imaging that TLS master secrets
ever would. So malware on a client machine could exfiltrate the TLS master
secret (along with whatever is needed to resume a TLS session from another
location), but it wouldn't be able to exfiltrate the ChannelID
(TokenBinding) key.

So I wanted clients to have to re-prove possession of their ChannelID
(TokenBinding) key on session resumption to defeat such an attack.

What do you guys think? Should we keep the current language in the
TokenBinding spec, or change it to match the ChannelID semantics?

Dirk.

On Tue, Sep 1, 2015 at 7:31 PM Andrei Popov <[email-masked]>
wrote:

>    and the server and SHALL be definitive for the *TLS session*.”
>
>
>
> Once TB parameters have been negotiated for a TLS session, they apply to
> all connections within that TLS session. There is no need to resend the
> extension on resumption. The application of course needs to send the Token
> Binding messages in every connection within such TLS session.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Bill
> Cox
> *Sent:* Tuesday, September 1, 2015 6:59 PM
> *To:* [email-masked]
> *Subject:* [Unbearable] What is the right action on TLS session
> resumption?
>
>
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 2 Sep 2015 17:55:25 +0000

Hi Dirk,

Ø  So I wanted clients to have to re-prove possession of their ChannelID (TokenBinding) key on session resumption to defeat such an attack.
TBPROTO still requires that the client prove possession of the TB key on each connection.

The Token Binding TLS extension establishes the Token binding protocol version and key parameters. Do you see a reason to renegotiate these parameters on every reconnect to the same server?

Basically, I agree that POP has to happen on every connection, but I thought that it is sufficient to negotiate TB key parameters once per session.

Cheers,

Andrei

From: Dirk Balfanz [mailto:[email-masked]]
Sent: Wednesday, September 2, 2015 10:32 AM
To: Andrei Popov <[email-masked]>; Bill Cox <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] What is the right action on TLS session resumption?

Interesting. From the original ChannelID draft<https://tools.ietf.org/html/draft-balfanz-tls-channelid-01#section-5>:

"Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection."

The reason we had decided to do it that way was the following: In the future, I imagined that ChannelID (i.e., TokenBinding) private keys would reside in protected hardware, but I didn't imaging that TLS master secrets ever would. So malware on a client machine could exfiltrate the TLS master secret (along with whatever is needed to resume a TLS session from another location), but it wouldn't be able to exfiltrate the ChannelID (TokenBinding) key.

So I wanted clients to have to re-prove possession of their ChannelID (TokenBinding) key on session resumption to defeat such an attack.

What do you guys think? Should we keep the current language in the TokenBinding spec, or change it to match the ChannelID semantics?

Dirk.

On Tue, Sep 1, 2015 at 7:31 PM Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bill,

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bill Cox
Sent: Tuesday, September 1, 2015 6:59 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Unbearable] What is the right action on TLS session resumption?

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

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 02 Sep 2015 17:55:27 +0000

Oh, never mind. The original question (and Andrei's response) was about the
negotiated algorithms (parameters), right? It's ok to fix those for the
whole session. And since tls-unique (or, as discussed in the other thread,
possibly a different extracted key) is unique for each connection, we do
actually get the intended semantics from the original ChannelID draft.

Dirk.

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 02 Sep 2015 17:58:01 +0000

Crossed emails. :-) Yes, what you said.

Dirk

On Wed, Sep 2, 2015 at 10:55 AM Andrei Popov <[email-masked]>
wrote:

> Hi Dirk,
>
>
>
> Ø  So I wanted clients to have to re-prove possession of their ChannelID
> The Token Binding TLS extension establishes the Token binding protocol
> version and key parameters. Do you see a reason to renegotiate these
> parameters on every reconnect to the same server?
>
>
>
> Basically, I agree that POP has to happen on every connection, but I
> thought that it is sufficient to negotiate TB key parameters once per
> session.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Dirk Balfanz [mailto:[email-masked]]
> *Sent:* Wednesday, September 2, 2015 10:32 AM
> *To:* Andrei Popov <[email-masked]>; Bill Cox <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Unbearable] What is the right action on TLS session
> resumption?
>
>
>