On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox <waywardg...@google.com> wrote:
> On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > >> On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <waywardg...@google.com> 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. > Yes, this is legal. I'll see if I can clarify this in the text. -Ekr 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
