On Mon, Mar 14, 2016 at 12:25 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
> (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? > As far as I can tell, there's no protocol difference between "stateful" and "stateless" resumption. You use the same techniques (a replay cache) and the question is merely whether the server actually maintains one. -Ekr > > Dave >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
