Subject: [Unbearable] For 0-RTT resumption, do we need to protect the resumption master secret (RMS) as strongly as the TB private key?

From: Bill Cox <[email-masked]>
Date: Wed, 7 Sep 2016 17:55:58 -0700

I was convinced that we did, but now I've forgotten the attack.  Assume the
server has token-binding-header replay protection, meaning that any given
valid TB header will ever only be accepted over one connection.  In this
case, a stolen RMS secret and also a stolen clear-text of a TB header used
in a PSK-0-RTT resume still cannot be used to make use of auth tokens by an
attacker.  She can create the same client hello as seen before, but then
the TB header will be rejected.

Am I thinking of the wrong attack?  Why again do we need to protect the RMS
secret as strongly as the TB key?

Bill

---

From: Bill Cox <[email-masked]>
Date: Wed, 7 Sep 2016 21:40:52 -0700

I went through this again, and I think I have it right now.  Assuming TLS
1.3 PSK 0-RTT resumption:

- Most servers will not bother with any replay protection.  Replay
protection for requests is hard (if you do this, I recommend plain-old
session caches - they're cheaper and easier than strike registers).  Replay
protection for TB headers over different connections is easy compared to
strike registers.  However, I suspect most servers will use neither.
- For non-replay-hardened 0-RTT enabled servers, the RMS is just as
sensitive as the TB private key.  For these companies, it would be silly to
issue hardware tokens containing TB private keys while storing RMS secrets
in memory or on disk.
- For the few (if any) companies that build effective replay protection,
securing TB private keys in hardware should offer additional defense,
stopping attackers from modifying user account data when the attacker has
the RMS, but cannot access the TB signing oracle.

I'm not sure if building TB header replay defense is worth it.  Without it,
over 0-RTT, which will become the law of the land, hardware secured TB keys
will be lame, because attackers will simply go after the RMS.  With TB
replay protection, we get most of the benefit of our old strike registers,
such as defense against "infinite" 0-RTT packet replay attacks, but we
can't stop the more clever request replay attacks.

What do you folks think?  "I don't give a &^%# about freakin TB header
replay protection" is a valid answer :)

Bill

---

From: Andrei Popov <[email-masked]>
Date: Thu, 8 Sep 2016 21:13:15 +0000

Hi Bill,

For my understanding, what do you mean when you talk about “replay protection for TB headers”?
It seems to me that a server farm that implements any form of TLS 1.3 0-RTT replay protection, will probably do it for all application_data, not just for TB headers.

I think these options are secure:

1.       The client protects both the TLS resumption secrets and TB keys equally.

2.       The server prevents the replay of 0-RTT application_data.

3.       TB is not used with 0-RTT.

The problem with #2 is that the client has no way to know whether 0-RTT replay protection is in effect for a particular server.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Wednesday, September 7, 2016 9:41 PM
To: Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] For 0-RTT resumption, do we need to protect the resumption master secret (RMS) as strongly as the TB private key?

I went through this again, and I think I have it right now.  Assuming TLS 1.3 PSK 0-RTT resumption:

- Most servers will not bother with any replay protection.  Replay protection for requests is hard (if you do this, I recommend plain-old session caches - they're cheaper and easier than strike registers).  Replay protection for TB headers over different connections is easy compared to strike registers.  However, I suspect most servers will use neither.
- For non-replay-hardened 0-RTT enabled servers, the RMS is just as sensitive as the TB private key.  For these companies, it would be silly to issue hardware tokens containing TB private keys while storing RMS secrets in memory or on disk.
- For the few (if any) companies that build effective replay protection, securing TB private keys in hardware should offer additional defense, stopping attackers from modifying user account data when the attacker has the RMS, but cannot access the TB signing oracle.

I'm not sure if building TB header replay defense is worth it.  Without it, over 0-RTT, which will become the law of the land, hardware secured TB keys will be lame, because attackers will simply go after the RMS.  With TB replay protection, we get most of the benefit of our old strike registers, such as defense against "infinite" 0-RTT packet replay attacks, but we can't stop the more clever request replay attacks.

What do you folks think?  "I don't give a &^%# about freakin TB header replay protection" is a valid answer :)

Bill

---

From: Bill Cox <[email-masked]>
Date: Fri, 9 Sep 2016 11:39:49 -0700

> protection for TB headers”?

This is different than replay protection for application requests.  For
example, a simple attack can cause the browser to re-issue requests that
have already been processed by the server over a new connection.  The
attacker simply blocks the server response to the first requests.  This is
extremely hard to defend against.  Those requests on the new connection
will carry different TB headers, so there is no TB header replay in this
attack, only request replay.  It turns out to be comparatively easy to
implement and deploy TB header replay protection that ensures TB headers
are accepted on only one connection.  This is partly because we can do this
in the back-end in standard data centers, rather than having to do it on
the machine that terminates TLS in random locations around the globe in
various types of clusters.  The other reason is that global synchronization
is not required, only synchronization at the scale where machines use the
same ticket decryption key (typically a metro area, I think).  Further, TB
replay protection is not time-critical like our strike registers were.  It
can be done in the back-end.  This seems to provide much of the benefit of
our old strike registers, with only a fraction of the pain.  It also seems
to bring 0-RTT token-binding security a lot closer to 1-RTT security.

> It seems to me that a server farm that implements any form of TLS 1.3
> 0-RTT replay protection, will probably do it for all application_data, not
> just for TB headers.
>

My guess is that full replay protection (requiring global synchronization),
will not be implemented by any big web sites.  It's too slow.  The partial
replay protection and improved forward secrecy gained when using session
caches might entice some of them to continue to support session caching,
which seems better than strike registers.  For sites that really want to go
to stateless (probably most big web sites), there will be no replay
protection on the front-end machines that terminate TLS.  However, the
authentication groups at those companies can still prevent TB replay in the
back-end, which offers most of the benefits of front-end request replay
protection.

It is going to be interesting to see what happens.

> 1.       The client protects both the TLS resumption secrets and TB keys
I am favor of protecting all secrets outside of the user process, but
that's another discussion.  Most apps just

> The problem with #2 is that the client has no way to know whether 0-RTT
> replay protection is in effect for a particular server.
>

 A client could test this easily.  I bet port scanners and similar tools
will be modified to detect this.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Mon, 12 Sep 2016 23:45:35 +0000

Ø   A client could test this easily.  I bet port scanners and similar tools will be modified to detect this.
Well, certainly a client can test. I doubt that Chrome is going to test each server for 0-RTT replay protection before sending 0-RTT application_data to them… ☺

Ø  Further, TB replay protection is not time-critical like our strike registers were.  It can be done in the back-end.
TB has to be validated before responding to a request, so it seems as time-critical as the request itself. Am I missing something?

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Friday, September 9, 2016 11:40 AM
To: Andrei Popov <[email-masked]>
Cc: Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] For 0-RTT resumption, do we need to protect the resumption master secret (RMS) as strongly as the TB private key?

On Thu, Sep 8, 2016 at 2:13 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bill,

This is different than replay protection for application requests.  For example, a simple attack can cause the browser to re-issue requests that have already been processed by the server over a new connection.  The attacker simply blocks the server response to the first requests.  This is extremely hard to defend against.  Those requests on the new connection will carry different TB headers, so there is no TB header replay in this attack, only request replay.  It turns out to be comparatively easy to implement and deploy TB header replay protection that ensures TB headers are accepted on only one connection.  This is partly because we can do this in the back-end in standard data centers, rather than having to do it on the machine that terminates TLS in random locations around the globe in various types of clusters.  The other reason is that global synchronization is not required, only synchronization at the scale where machines use the same ticket decryption key (typically a metro area, I think).  Further, TB replay protection is not time-critical like our strike registers were.  It can be done in the back-end.  This seems to provide much of the benefit of our old strike registers, with only a fraction of the pain.  It also seems to bring 0-RTT token-binding security a lot closer to 1-RTT security.

My guess is that full replay protection (requiring global synchronization), will not be implemented by any big web sites.  It's too slow.  The partial replay protection and improved forward secrecy gained when using session caches might entice some of them to continue to support session caching, which seems better than strike registers.  For sites that really want to go to stateless (probably most big web sites), there will be no replay protection on the front-end machines that terminate TLS.  However, the authentication groups at those companies can still prevent TB replay in the back-end, which offers most of the benefits of front-end request replay protection.

1.       The client protects both the TLS resumption secrets and TB keys equally.
I am favor of protecting all secrets outside of the user process, but that's another discussion.  Most apps just

 A client could test this easily.  I bet port scanners and similar tools will be modified to detect this.

Bill

---

From: Bill Cox <[email-masked]>
Date: Mon, 12 Sep 2016 23:40:15 -0700

On Mon, Sep 12, 2016 at 4:45 PM, Andrei Popov <[email-masked]>
wrote:

> Ø  Further, TB replay protection is not time-critical like our strike
> registers were.  It can be done in the back-end.
>
> TB has to be validated before responding to a request, so it seems as
> time-critical as the request itself. Am I missing something?
>

TB verification can be done in the back-end as well, making it a lot less
time sensitive.  Strike registers were in the critical path to terminating
QUIC encryption, and were in the critical path to making connections, just
like a session cache.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Tue, 13 Sep 2016 17:49:48 +0000

TB message replay protection would make it possible to use TB with TLS 1.3 0-RTT, even when the TLS resumption secret is not as strongly protected as the TB key. When we author our TLS13TB document, I think we should include this option.

The question is, how does the client know the server is doing TB message replay protection? Perhaps we could have the server indicate TB message replay protection status during the TB negotiation (in the 1-RTT handshake).

Cheers,

Andrei

Sent: Monday, September 12, 2016 11:40 PM

On Mon, Sep 12, 2016 at 4:45 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

>  Further, TB replay protection is not time-critical like our strike registers were.  It can be done in the back-end.

TB verification can be done in the back-end as well, making it a lot less time sensitive.  Strike registers were in the critical path to terminating QUIC encryption, and were in the critical path to making connections, just like a session cache.

Bill

---

From: Bill Cox <[email-masked]>
Date: Tue, 13 Sep 2016 13:10:57 -0700

On Tue, Sep 13, 2016 at 10:49 AM, Andrei Popov <[email-masked]>
wrote:

> TB message replay protection would make it possible to use TB with TLS 1.3
> 0-RTT, even when the TLS resumption secret is not as strongly protected as
> the TB key. When we author our TLS13TB document, I think we should include
> this option.
>
>
>
> The question is, how does the client know the server is doing TB message
> replay protection? Perhaps we could have the server indicate TB message
> replay protection status during the TB negotiation (in the 1-RTT handshake).
>

I like that option, though I think we discussed something like that for
application request replay protection on the TLS 1.3 WG list, and I don't
think it went very far, but my memory is flawed.  I guess my preference
would be for clients to know if there is any replay protection before
deciding to use PSK 0-RTT resumption.  I think there was some discussion
about putting that as a flag in the ticket, kind of like the lifetime hint.

Bill