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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
