Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)

[Martin Thomson <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>