Just how strict do we want to be with forward secrecy? The choices I see are:
1) Avoid 0-RTT connections, and do only 1-RTT connections when we want strict forward secrecy and strong client authentication 2) Keep server-side state for decrypting each ticket, and issue new tickets on each connection, while avoiding 0-RTT replay to the same data center. 3) Give up on first flight forward secrecy, as well as client authentication for first flight data. If tickets are reused for multiple 0-RTT resumptions, then the earlier connections can be decrypted using whatever state the server keeps to decrypt later connections. I think option 1 simple and secure, but is too slow. The choice between 2) and 3) is a security vs cost and complexity trade-off. No new functionality is required to implement 1, 2, or 3, I think. It can be up to the implementation and application. Is it worth spelling out in the spec the gory details? I'm trying out some language for implementing 2, and the downsides for 1 and 3. Not sure if it belongs... Bill
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
