On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox <waywardg...@google.com> wrote:
> AFAIK, there has never been a session resumed with forward secrecy. Is > this correct? > Yes, session resumption does not have PFS. Though note that with 1.3 that will no longer be true, because you can do PSK-DHE. > In the past, there were two cases: resumption using session IDs, and > resumption with session tickets. Using session IDs loses forward secrecy, > because the server always has session keys in a session cache, which could > be used to decrypt the prior sessions. Using tickets did not work either, > because the server always kept a ticket decryption key which could be used > to decrypt all resumed sessions since the key was last rotated. > Well, the server could in principle delete the keys from the session cache and (at more cost) the decryption key But yes. > To have forward secrecy under the strict definition using the new PSK > scheme, we need to use what the new name implies: pre _shared_ keys. The > new name implies that the server remembers a unique shared key for the > connection, which is server-side state per resumable connection. If we > only store the PSK in the ticket, and go stateless on the server, then the > server-side ticket decryption key again defeats strict forward secrecy. > With a remembered server-side pre-shared secret, we can have a 0-RTT resume > with strict forward secrecy. Is this already implied in the spec? If so, > the spec could be improved, by stating this explicitly. However, the > current statement that 0-RTT does not provide forward secrecy seems to be > wrong in the case that we resume a 0-RTT connections with a > server-remembered PSK. > > To have strict forward secrecy, given that the server already has to have > server-side state (the pre-shared key), I find the old session ID scheme > more palatable than the new tickets. The main point of session tickets was > to eliminate the server-side session cache, wasn't it? > The current ticket scheme is compatible with either a server-side database *or* having self-contained tickets which are encrypted with a server-side key. (This was also true for tickets, it's just that you didn't bother with tickets if that is what you wanted). If you want a database, you just use an identifier as the key name. The point is to have a mechanism which accomodates either design. I think the current spec does not describe well enough how to implement > secure 0-RTT infrastructure. Instead, it seems to recommend against using > 0-RTT, with a pretty dire warning about the insecurity of 0-RTT. > Well, the primary purpose of this warning isn't to warn about PFS. It's really to warn about the replay issue, which is unique to 0-RTT and which can't really be fixed by proper implementation. The issue isn't that it's not possible to have anti-replay if you're willing to store server side state, but rather how you respond to server-side state loss. Moreover, the problems exist whether or not you use certificate-based client authentication. I haven't thought this through in as much detail as I've thought through the non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the problems with replay. The basic issue is the same: what happens when a server gets a connection attached to state which it doesn't have. So, what the attacker would do duplicate the ClientHello + PSK and send one copy to the true datacenter and one to another datacenter that doesn't have state. The right datacenter will process the 0-RTT handshake and the wrong one will reject it, causing the client to fall back to 1-RTT and retransmit the request. So, you still get replay. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
