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

[Nick Harper <[e-mail]>]

On Thu, Oct 1, 2020 at 7:05 AM Michael D'Errico <[e-mail]> wrote:

> > I am having a difficult time understanding the tradeoffs you're facing.
>
> This is the first time I'm reading the TLS 1.3 RFC.  I have
> implemented SSLv3, TLS 1.0, 1.1, and 1.2.  You may have
> used my test server at https www dot mikestoolbox dot
> org or dot net to test your own code.  It's kind of old now
> since it doesn't do ECC and the DHE_RSA key exchange
> I focused on has been disabled by most clients so you
> end up getting a regular RSA handshake now.
>
> I have gotten caught by the stateless HelloRetryRequest
> and can't get past it.  You can't possibly implement it the
> way the spec suggests with just a hash in a HRR cookie
> extension.


The only thing the server needs to know is the hash of the ClientHello (so
it can restore the transcript hash) and that the server has already sent a
HelloRetryRequest (which it can detect by presence of the cookie). The only
argument I've seen made for what the spec suggests not working is being
able to verify which fields changed between ClientHello1 and ClientHello2.
I see no language in RFC 8446 that the server MUST enforce that the
ClientHello2 is conformant with respect to ClientHello1. Thus, I think what
the spec suggests should work.


> If it can be done at all, the stateless server
> should probably just put the ClientHello1 and HRR (minus
> the cookie) into the cookie extension.  If this is how it
> should be done, then the spec should say so -- exactly
> how to do it so everyone does it the same (correct) way
> and not just hand-wave it and say figure it out yourself.
>
> Getting the cookie right isn't enough because of the
> potential for resending an old cookie by a mischievous
> client.


The cookie serves as an alternative way for the server to remember the
ClientHello1 sent by the server. If the client is trying to perform some
sort of attack on the server by re-sending an old cookie, I assume that a
prerequisite for this attack is that the TLS handshake succeeds. For the
handshake to succeed, the client needs to know the ClientHello1 that
corresponds to the cookie so that it can compute the transcript hash
correctly. Regardless of the source of that client hello, the client can
equivalently send that ClientHello, get a real HelloRetryRequest from the
server, and send its ClientHello2, or it can send a ClientHello with the
cookie, bypassing the step of waiting for the HRR. A client attempting to
do something malicious with an HRR cookie is equivalent to behavior that
does not depend on a cookie.

>
> Mike
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>