On Tue, Nov 3, 2015 at 7:16 AM, David Mazieres < [email protected]> wrote:
> 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. Sure; it's just not clear from the document that it's okay for a server to accept SID[i+1] when it was expecting SID[i]: "The active opener MUST use the lowest value of "i" that has not already appeared in a resumption suboption exchanged with the same host and for the same pre-session seed." The MUST here seems to be implying that the only way to get the server to recognize an SID is to choose the one it's expecting. Since SYN packets may be reordered, this is best-effort. > > 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. > I wasn't suggesting implementing session tickets; I'm just trying to explore the consequences of this approach. It seems that without complicating matters greatly (e.g., offering multiple SIDs, one for every session the client has negotiated recently), the onus is on the server to make session caching useful through client stickiness or state sharing. Which is perfectly fine. Kyle
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
