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

[Benjamin Kaduk <[e-mail]>]

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.