(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 <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 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
