Kyle Rose <[email protected]> writes: > If a client opens two connections to a previously-known server in a short > period of time, what is the intended behavior of implementations?
The keys are derived in such a way that you can precompute serveral session IDs and associated keys without harming privacy. So you can easily tolerate a little bit of reordering. Even if one of the SIDs ends up not being used and you cache it for a long period of time, later connections will still enjoy forward secrecy. > I will note that I'm not sure how this would work in the case of server > farms all responding for the same IP. Without state sharing, it seems like > session resumption wouldn't work at all without client stickiness, which is > one advantage of TLS's session ticket mechanism; but then with session > tickets and similar constructs you run into replay issues for early data on > 0RT connections. You are correct that this would require client stickiness. Session tickets are unlikely to meet the TCPINC charter's requirements for forward secrecy. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
