[TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data)

[Dave Garrett <[e-mail]>]

(This thread has gotten long and winding, so I'm replying to these two portions bellow under a new subject. Reply after quotations.)

On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote:
> 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

On Monday, March 14, 2016 08:10:32 am Nikos Mavrogiannopoulos wrote:
> It is important to see how protocols are perceived. For many people TLS
> 1.3 with 0rtt will be the same as TLS 1.3. The first publication of an
> attack against TLS 1.3 with rtt, will be perceived as an attack against
> TLS 1.3 protocol. Even if the published attack against TLS 1.3 with
> 0rtt was an expected one (i.e., replay of data), if the attack impact
> is high, that may not be sufficient to stop the avalanche of bad
> publicity. In turn that will lead several people losing confidence to
> TLS 1.3 as a protocol, even TLS and the IETF process overall.
>  
> My suggestion, if you need 0rtt, publish it as a different document,
> don't mix it with TLS 1.3. The security requirements from TLS are
> vastly different from the security requirements of a 0rtt protocol.

Previous discussion seemed to land on the conclusion that semi-static DH 0RTT should be defined in a separate document, and after this discussion I'm beginning to agree that all stateless 0RTT should be defined as a separate companion document to the main TLS 1.3 specification. We can likely agree on defining a stateful 0RTT PSK resumption system which is sufficiently safe and mistake-resistant, and we could restrict the official TLS 1.3 spec to only specify that, whilst referencing the other document as a more experimental feature that could be available to certain applications (possibly a non-standards-track document). HTTPS could then, itself, have a separate document laying out the necessary practices to do stateless 0RTT safely, and other applications should be warned that without a similar such document, things are very risky.

Is this in the ballpark of what the WG could agree on to help mitigate some of the problems here?


Dave