If a client opens two connections to a previously-known server in a short period of time, what is the intended behavior of implementations?
If one session resumption attempt uses SID[i] and another SID[i+1], then if they arrive out of order, should the server ignore (or simply not recognize) SID[i+1] and initiate a new key agreement, but then accept SID[i] when it eventually arrives? What, then, should happen on the client? Should the client use SID[i+2] for the next connection to this server, or will it use a different SID based on the new key agreement? Or, alternatively, should one connection use SID[i], and the next not send a TCPCRYPT_RESUME because the previous handshake has not yet been completed? I know this isn't specified in the draft because it's out-of-scope for the protocol spec, but I think it's worth puzzling out how clients would actually do this in the wild because this is likely to be a common case. One way to resolve this is for clients only to ever have one SID[I] for a given ss[] chain in-flight in a handshake, and request a new key agreement otherwise; but to keep multiple chains for a given server cached so the number of key agreements required over the session cache lifetime is bounded by the maximum number of simultaneous handshake attempts rather than by the total number of handshakes minus epsilon as it could otherwise be in the pessimal case. 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. Kyle
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
