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

[Bill Cox <[e-mail]>]

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

> On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox <[e-mail]> wrote:
>
>> AFAIK, there has never been a session resumed with forward secrecy.  Is
>> this correct?
>>
>
> 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.
>

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.

>
>
>> 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.
>>
>
> Well, the server could in principle delete the keys from the session cache
> and (at more
> 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.

> 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
> 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.
>

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.


> 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.
>>
>
> 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.
>

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


> 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
>

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 <[e-mail]> wrote:

> On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox <[e-mail]> wrote:
>
>> AFAIK, there has never been a session resumed with forward secrecy.  Is
>> this correct?
>>
>
> 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.
>
>
>
>
>> 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.
>>
>
> Well, the server could in principle delete the keys from the session cache
> and (at more
> cost) the decryption key But yes.
>
>
>
>
>> 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?
>>
>
> 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.
>
>
> 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.
>>
>
> 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
>
>
>