The costs you describe are trivial. And we limit replay with a binding to remote address, and a short timer. But the benefit is mostly down to reduced code variations. We also implement DTLS where this is properly useful.
On Wed, Sep 30, 2020, at 15:11, Michael D'Errico wrote: > [I'm resending this with a more appropriate Subject line. --Mike] > > On 9/29/20 19:51, Martin Thomson wrote: > > It's symmetric crypto[1]. Hardly worth noting. > > [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that > > server clusters can share session ticket encryption keys without needing > > interconnects. But encryption or decryption only happens once per instance. > > Well, you also need a MAC, right? (encrypt-then-mac) > This requires another key and a bunch of computation. > > Then you have to decode the cookie back into the server > state, and then check whether the new ClientHello (CH) > matches the original from the cookie, with possible > changes, making sure that the key_share supplied in > the new CH was in the original CH, checking that the > list of PSK's was not tampered with in invalid ways, etc. > Much of this is required of any handshake involving HRR > even if not stateless. > > Seems worth noting. Have you measured? > > And how do you prevent someone from sending an old > cookie back? If the server is truly stateless.... > > Did you (or a client) actually have a data center full of > memory-bound servers which are now handling many > more connections using the stateless HRR feature? > > I'm not trying to be unkind, I genuinely don't understand > how stateless HRR can be beneficial. > > Mike > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
