Hi Mike, On Wed, Sep 30, 2020 at 01:20:59PM -0400, Michael D'Errico wrote: > > The costs you describe are trivial. > > The general idea among developers these days that CPU > cycles are free is a huge problem. > > You didn't answer my biggest question, though, which was > whether you (or anybody else!) has had success using stateless > HelloRetryRequest to increase the number of connections a > datacenter can handle due to the fact that the servers were > memory-bound. The amount of memory to hold the first
Could you say a bit more about why you think that demonstration of production-grade usage in (non-D) TLS is needed in order to justify this portion of the specification? Note that you can use HRR without cookie just fine. The HelloRetryRequest message has to exist in TLS 1.3 in order to cope with the case where the client's optimistic key_share is not acceptable to the server, and another round-trip is needed in order to get key shares for the proper group. Give that there will be an HRR message, it seems/seemed quite prudent to build out all the bits that DTLS would need from a HRR, since we knew DTLS 1.3 was coming in short order, and we want DTLS 1.3 to be as small a diff from TLS 1.3 as possible. While you might in theory want to or be able to use TLS 1.3 HRR+cookie to decrease state keeping at the server, that's not (IMO) the main reason it exists, and so I don't see a need for anyone to demonstrate that they have done so in order to justify this portion of the specification. The text about allowing stateless offload being a primary purpose for cookie can be true even though it is not directly utilized in regular TLS. With respect to the "hash of the ClientHello" question and how much state is needed, the idea is that the ways in which the second ClientHello can differ from the original ClientHello are tightly constrained, such that the original ClientHello can be reconstructed by the server given the second ClientHello and an honest client. If the hash of the reconstructed version does not match the hash saved in the cookie, you assume that some form of attack is underway and abort the connection. You can also do fancier things as has already been described, but that is part of the origin of the "hash of the ClientHello" text. (You do also need the hash value to complete the transcript, as Watson noted.) With respect to HRR being a weird instance of ServerHello instead of a "proper" message in its own right, yes, that is weird. It was originally a separate message, and then real-world deployment showed that there were too many deployed middleboxes that would choke on a new message type, and we had to come up with a *lot* of awkward hacks to provide "middlebox compatibility mode" (see section D.4). It seems simpler to make HRR always be the middlebox-compatible version rather than have two ways to spell it, so that's why it's the way it is. -Ben P.S. If you felt like doing some experiments to see how the stateless HRR affects the memory/CPU balance, it is implemented in openssl. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
