Subject: [TLS] Forward secrecy with resumption, and 0-RTT security

From: Bill Cox <[email-masked]>
Date: Sun, 6 Dec 2015 06:50:04 -0800

AFAIK, there has never been a session resumed with forward secrecy.  Is
this correct?

In the past, there were two cases: resumption using session IDs, and
resumption with session tickets.  Using session IDs loses forward secrecy,
because the server always has session keys in a session cache, which could
be used to decrypt the prior sessions.  Using tickets did not work either,
because the server always kept a ticket decryption key which could be used
to decrypt all resumed sessions since the key was last rotated.

My first question is: Do we care?

The original definition of forward secrecy seemed to mean forward secrecy
for all sessions older than the key rotation interval.  This is what
Twitter had when claiming support for forward secrecy.  Do I understand
this correctly?  However, the new definition we seem to be using now is
that no past session can be decrypted using server-side state that persists
after the connection ends.  Under this definition, AFAIK, there has never
been a resumable session with forward secrecy.  Is this definition taking
forward secrecy too far?

To have forward secrecy under the strict definition using the new PSK
scheme, we need to use what the new name implies: pre _shared_ keys.  The
new name implies that the server remembers a unique shared key for the
connection, which is server-side state per resumable connection.  If we
only store the PSK in the ticket, and go stateless on the server, then the
server-side ticket decryption key again defeats strict forward secrecy.
With a remembered server-side pre-shared secret, we can have a 0-RTT resume
with strict forward secrecy.  Is this already implied in the spec?  If so,
the spec could be improved, by stating this explicitly.  However, the
current statement that 0-RTT does not provide forward secrecy seems to be
wrong in the case that we resume a 0-RTT connections with a
server-remembered PSK.

To have strict forward secrecy, given that the server already has to have
server-side state (the pre-shared key), I find the old session ID scheme
more palatable than the new tickets.  The main point of session tickets was
to eliminate the server-side session cache, wasn't it?

I think the current spec does not describe well enough how to implement
secure 0-RTT infrastructure.  Instead, it seems to recommend against using
0-RTT, with a pretty dire warning about the insecurity of 0-RTT.  I think
that nearly the entire world will switch to 0-RTT, regardless of security
limitations and warnings.  Companies won’t be able to resist the improved
connection time.  IMO, the spec should describe how to address the security
issues with 0-RTT, rather than just warning about security issues.

So, here are my dumb thoughts about practical 0-RTT security
infrastructure...

One way is to bind resumption to orbits, by having only the orbit that
issues a PSK remember the secret key.  Something like this is needed in any
case to provide 0-RTT replay protection.  Without at least orbit-based
replay protection, I think it does not make sense to allow a ClientVerify
in a 0-RTT connection.

There was a TODO in the last version I read asking what the client would
sign in a 0-RTT ClientVerify.  If orbit-based replay protection is in place
using PSKs, then signing anything that identifies what PSK to use is
enough. However, the handshake has to somehow be bound to the orbit to
prevent the signature from being replayed in a MitM attack. Having a ticket
that can only be decrypted using the orbit-specific ticket decryption key
would work. Using a source address token bound to the orbit would also
work.  Signing the server Finish is not required to insure the signature
will only be accepted once.

There are two parts to a proof-of-possession: uniqueness and freshness.
Uniqueness can be had using orbit-bound PSKs.  Insuring freshness is
harder.  This could be done by adding timestamps to the material signed.
With this, we would not get a complete proof of possession, because an
attacker can attack the client's clock, unlike a normal proof of
possession.  However, if steps are taken to secure clocks, which is needed
for TLS in any case, then we can get what I think of as "compelling
evidence" of possession, which might be good enough.

I think I've partially covered all three security concerns listed for 0-RTT
connections: forward secrecy, replay protection, and client certs.  The
limitations seem to be:

   -

   0-RTT resumption using PSK can address all 3, but not 0-RTT connections
   -

   Strict forward secrecy requires server-side state, so why are we using
   tickets?
   -

   Replay protection based on orbits is only partial protection
   -

   ClientVerify can only provide “compelling evidence”, rather than proof
   of possession

It concerns me that the TLS 1.3 spec seems to say "Don't use 0-RTT!  It's
not secure!" when it is clear that the world will go in that direction.  I
would feel a lot better if the spec had more discussion about how to do
0-RTT securely.

Thoughts?

Bill

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Dec 2015 07:12:35 -0800

> AFAIK, there has never been a session resumed with forward secrecy.  Is

Yes, session resumption does not have PFS. Though note that with 1.3 that
will
no longer be true, because you can do PSK-DHE.

> to decrypt all resumed sessions since the key was last rotated.

Well, the server could in principle delete the keys from the session cache
and (at more
cost) the decryption key But yes.

> to eliminate the server-side session cache, wasn't it?

The current ticket scheme is compatible with either a server-side database
*or* having self-contained
tickets which are encrypted with a server-side key. (This was also true for
tickets, it's just that
you didn't bother with tickets if that is what you wanted). If you want a
database, you just use
an identifier as the key name. The point is to have a mechanism which
accomodates either
design.

> 0-RTT, with a pretty dire warning about the insecurity of 0-RTT.
>

Well, the primary purpose of this warning isn't to warn about PFS. It's
really to warn
about the replay issue, which is unique to 0-RTT and which can't really be
fixed
by proper implementation. The issue isn't that it's not possible to have
anti-replay
if you're willing to store server side state, but rather how you respond to
server-side state
loss. Moreover, the problems exist whether or not you use certificate-based
client authentication.

I haven't thought this through in as much detail as I've thought through the
non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the
problems with replay. The basic issue is the same: what happens when
a server gets a connection attached to state which it doesn't have. So,
what the attacker would do duplicate the ClientHello + PSK and send one
copy to the true datacenter and one to another datacenter that doesn't have
state. The right datacenter will process the 0-RTT handshake and the
wrong one will reject it, causing the client to fall back to 1-RTT and
retransmit
the request. So, you still get replay.

-Ekr

---

From: Bill Cox <[email-masked]>
Date: Sun, 6 Dec 2015 08:17:04 -0800

> no longer be true, because you can do PSK-DHE.

With PSK-DHE over 0-RTT, would we use the static DHE server share for the
first resume flight?  In that case, we still lose first flight strict
forward secrecy, though with 1-RTT it seems to work perfectly.  I just have
doubts that 1-RTT is going to be used much.

> cost) the decryption key But yes.
It could also just rekey the keys by hashing them, or something like that.
With server-side state, forward secrecy seems straight forward to achieve.

> tickets which are encrypted with a server-side key. (This was also true
> for tickets, it's just that

I think this is a very cool aspect of TLS 1.3.  Inefficiencies always bug
me, though.  It is somewhat painful transmitting 0's in the SessionID
field, when we could use that to lookup saved server-side state, reducing
or eliminating the ticket while still supporting 0-RTT resume.  However, I
lean pretty far on the side of efficiency.  Microseconds and bytes matter,
IMO.

> if you're willing to store server side state, but rather how you respond
> to server-side state

Agreed.  The anti-replay warning should remain.  We can mitigate, but not
eliminate this issue.

> the request. So, you still get replay.

Correct.  PSK does not solve this replay issue.  It only defends against
replay to the same data center. This increases the complexity of the attack
and limits the number of times a packet can be replayed, but does not solve
the replay issue.  Further mitigation steps, such as making all requests
idempotent (regardless of 0-RTT or 1-RTT), should be taken above the TLS
layer, at the application layer.  Datacenter bound PSK 0-RTT does solve the
uniqueness problem with ClientVerify signatures.  There would be at most
one accepted flight of packets per signing operation, even in your attack
scenario.

IMO, ClientVerify should only be supported if this weaker form of replay
protection is in place.  Here's a threat model:

A woman enters a hotel lobby, desperate for access to an online computer.
She uses a computer in the "business center" to access her online account,
which requires her to insert her security key containing her client
certificate.  When she's done with her work, she logs out, removes the
security key, and just to be safe smashes the computer into useless bits.

The attacker who previously installed malware on the computer now is able
to make a large number of new authenticated connections over several days,
with many connections in parallel, even though he no longer has access to
the security key to act as a signing oracle.

This is what you get using ClientVerify without taking steps to verify both
uniqueness and freshness of signatures.  If you only insure freshness, you
get a bunch of parallel authenticated connections that are long-lasting.
If you only insure uniqueness, you get malware using the security key
rapid-fire as a signing oracle to authorize many new connections in the
future.  You have to have both uniqueness and freshness in a useful
proof-of-possession.  We can insure uniqueness, and if the security key in
this case had an accurate clock, we could also insure freshness.

Another thing: resumption in TLS 1.2 breaks this security key scenario as
well.  Malware simply exports the session state and resumption ticket, and
the attacker then resumes authenticated connections without access to the
security key.  To fix this, there needs to be a new PoP per connection, not
just once on the initial handshake.

I guess another question is: Do we care about strong client authentication
enough to support it in a 0-RTT world?  The default solution when using TLS
1.3 is for companies that use security keys to never use 0-RTT
authentication.  That's not the end of the world, but I imagine that having
to support 0-RTT for regular users, and forcing 1-RTT for employees and
users who choose a higher level of security is going to be a complication.

I still think some more text describing 0-RTT implementation techniques
would be a good thing.  It really does read as if the spec is saying that
servers SHOULD NOT support 0-RTT.  I've never read a security warning like
that which did not have a SHOULD NOT associated with it.  Of course, I
haven't read that many IETF specs yet :)

Bill

On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla <[email-masked]> wrote:

> tickets which are encrypted with a server-side key. (This was also true
> for tickets, it's just that
> if you're willing to store server side state, but rather how you respond
> to server-side state

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Dec 2015 11:39:14 -0800

On Sun, Dec 6, 2015 at 8:17 AM, Bill Cox <[email-masked]> wrote:

> first resume flight?

No. In All PSK-DHE modes, the PSK is used as SS.

>> The current ticket scheme is compatible with either a server-side
>> database *or* having self-contained

You're talking about the single byte that indicates an empty session id?
That doesn't seem like
it's a big source of inefficiency.

> the security key to act as a signing oracle.

Yes, assuming the malware captures the client's DHE share.  I've updated
the draft to make this
point clear.

To be clear, the original issue with replay would still apply here as well,
since the client
would just sign twice.

> just once on the initial handshake.

Yes, that's one reason that people require fresh signatures on subsequent
connections
in systems like FIDO, even though they have a token that demonstrates
continuity of
the client (though typically that token is a cokie).

> users who choose a higher level of security is going to be a complication.

Yes, I think it's important, especially for WebRTC.

> haven't read that many IETF specs yet :)

I'll but it on my TODO list but I would definitely welcome a PR here.

Thanks,
-Ekr

>> Well, the server could in principle delete the keys from the session
>> cache and (at more
>>> To have strict forward secrecy, given that the server already has to
>>> have server-side state (the pre-shared key), I find the old session ID
>>> scheme more palatable than the new tickets.  The main point of session
>>> tickets was to eliminate the server-side session cache, wasn't it?
>>>
>>
>> The current ticket scheme is compatible with either a server-side
>> database *or* having self-contained
>> about the replay issue, which is unique to 0-RTT and which can't really
>> be fixed

---

From: Bill Cox <[email-masked]>
Date: Sun, 6 Dec 2015 12:30:14 -0800

> No. In All PSK-DHE modes, the PSK is used as SS.

That's cool.  I need to re-read the spec more carefully.

> it's a big source of inefficiency.

Ah... I did not realize it is u8-length encoded.  One byte bothers me a lot
less.

> Yes, I think it's important, especially for WebRTC.

OK... one more spec to read.

> I'll see if I can put together some text that would help me understand a
bit better, though as you can see from my emails so far, writing is not my
strong suit.

Bill

---

From: Bill Cox <[email-masked]>
Date: Sun, 6 Dec 2015 14:55:20 -0800

Just how strict do we want to be with forward secrecy?  The choices I see
are:

1) Avoid 0-RTT connections, and do only 1-RTT connections when we want
strict forward secrecy and strong client authentication
2) Keep server-side state for decrypting each ticket, and issue new tickets
on each connection, while avoiding 0-RTT replay to the same data center.
3) Give up on first flight forward secrecy, as well as client
authentication for first flight data.

If tickets are reused for multiple 0-RTT resumptions, then the earlier
connections can be decrypted using whatever state the server keeps to
decrypt later connections.

I think option 1 simple and secure, but is too slow.  The choice between 2)
and 3) is a security vs cost and complexity trade-off.

No new functionality is required to implement 1, 2, or 3, I think.  It can
be up to the implementation and application.  Is it worth spelling out in
the spec the gory details?

I'm trying out some language for implementing 2, and the downsides for 1
and 3.  Not sure if it belongs...

Bill

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 6 Dec 2015 15:00:23 -0800

> My first question is: Do we care?

At least for session tickets, I don't care. There's a simple enough way to
solve that problem: rotate the session ticket key every few days.

-- 
Tony Arcieri

---

From: Bill Cox <[email-masked]>
Date: Sun, 6 Dec 2015 15:07:29 -0800

> solve that problem: rotate the session ticket key every few days.

I tend to agree.  The difference between 100% forward secrecy and the old
weaker version where sessions become forward secure after a few days is not
a huge deal.

What do you think about client authentication for first flight data?  It is
possible, but painful to implement.

Bill

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 8 Dec 2015 17:26:20 -0600

On 12/06/2015 08:50 AM, Bill Cox wrote:
> I think the current spec does not describe well enough how to
> implement secure 0-RTT infrastructure.  Instead, it seems to recommend
> against using 0-RTT, with a pretty dire warning about the insecurity
> of 0-RTT.  I think that nearly the entire world will switch to 0-RTT,
> regardless of security limitations and warnings.  Companies won’t be
> able to

Perhaps I am living under a rock, but I do not have the sense that
"nearly the the entire world will switch to 0-RTT".

> resist the improved connection time.  IMO, the spec should describe
> how to address the security issues with 0-RTT, rather than just
> warning about security issues.
>
> issues a PSK remember the secret key.  Something like this is needed
> in any case to provide 0-RTT replay protection.  Without at least
> orbit-based replay protection, I think it does not make sense to allow
> a ClientVerify in a 0-RTT connection.
>
>
> There was a TODO in the last version I read asking what the client
> would sign in a 0-RTT ClientVerify.  If orbit-based replay protection
> is in place using PSKs, then signing anything that identifies what PSK
> to use is enough. However, the handshake has to somehow be bound to
> the orbit to prevent the signature from being replayed in a MitM
> attack. Having a ticket that can only be decrypted using the
> orbit-specific ticket decryption key would work. Using a source
> address token bound to the orbit would also work.  Signing the server
> Finish is not required to insure the signature will only be accepted once.
>
>
> There are two parts to a proof-of-possession: uniqueness and
> freshness.  Uniqueness can be had using orbit-bound PSKs.  Insuring
> freshness is harder.  This could be done by adding timestamps to the
> material signed.  With this, we would not get a complete proof of
> possession, because an attacker can attack the client's clock, unlike
> a normal proof of possession.  However, if steps are taken to secure
> clocks, which is needed for TLS in any case, then we can get what I
> think of as "compelling evidence" of possession, which might be good
> enough.
>
>

Perhaps I do not fully understand the proposal, but binding to source
address and signing timestamps sound an awful lot like things that have
been causing headaches for *decades* in the Kerberos community.  I would
be wary of introducing them into TLS.

-Ben