Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Bill Cox <[e-mail]>]

On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh <[e-mail]>
wrote:

> On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <[e-mail]> wrote:
>
>> As we all know, what matters most in security is the default mode.  I am
>> suggesting making the default 0-RTT resumption mode stateful, with a
>> documented session-ID (and let's bring back the timestamp, too, since we'll
>> need it).
>>
>
> Having state would make things much more robust; but rather than the state
> being around the channel itself (the TLS session), would it be more robust,
> and more flexible, for the state to be around the action? like some kind of
> hint cookie.
>

It looks like server-side state is required to prevent replay.  I don't
think any kind of token, cookie, or server-config can fix this.


> One of the problems with session resumption is that in order to be replay
> safe; the sequence number has to restart where it left off. That requires
> some kind of transactional store, and if you're doing all of this for
> latency, you may end up eating all of the wins there.
>

The new tickets can in theory end the debate over session caching vs
session tickets, since they can be used for database lookups or contain an
encrypted session state.  However, the spec does not document how to do
session caching with tickets securely, which looks tricky.  In reality, if
I were trying to build a speed and security sensitive site using TLS 1.3
stateful 0-RTT resumption, I would probably do something like this:

During the initial 1-RTT handshake:
- create a ticket containing only the session ID, resumption count, and a
session decryption key
- encrypt the session cache entry with the session encryption key stored in
the ticket
- encrypt the ticket with a semi-static ticket encryption key, which I
would rotate every few weeks
- send the ticket to the client, which is after encryption is enabled on
the connection

During a 0-RTT resume handshake:
- check for a cache hit, and drop to 1-RTT if not found
- decrypt the ticket with ticket the semi-static ticket decryption key
- decrypt the cached session state with the session key from the ticket
- compare the resumption counts in the session state and ticket, and fall
back to 1-RTT if they do not match
- increment the resumption count
- create a new session ticket with a new session encryption key and the
updated resumption count
- encrypt the session cache entry with the new session encryption key
- send the client the new ticket

I assume that it is legal to send a new ticket on a 0-RTT PSK resume, but
it is not clear to me from the drawings in the spec.  It is not shown as an
option.  This is required for secure stateful 0-RTT resumption.

I think this scheme minimizes data sent over the wire (to reduce latency)
and provides improved PFS vs using a non-encrypted session cache.  Since
tickets are sent after encryption has been enabled, leaking the semi-static
ticket encryption key does not enable an eavesdropper to decrypt past
sessions, as was the case in TLS 1.2.  If the server is compromised, this
scheme protects the session cache from being decrypted, so PFS is
preserved, unlike the case with either TLS 1.2 session caches with no
encryption or TLS 1.2 tickets with semi-static ticket keys.  Leaking either
the session cache or ticket encryption key would allow prior TLS 1.2
sessions to be decypted.

Bill