Anyway, back on the topic of stateless HelloRetryRequest, I
don't see how this can work given that the client can make
several modifications to the ClientHello which will invalidate
the hash sent in the "cookie" (even if the client echos it back
as required without modification).
The hash isn't used for validation, but for continuing the running
hash of the transcript to ensure that the negotiation isn't interfered
with. See section 4.4.1.
There may be a problem here if you try to implement the
stateless HelloRetryRequest the way the spec. implies (by
sending a hash of ClientHello1 in the "cookie" extension).
A non-conforming client can send an initial ClientHello1,
which both client and server know so they can compute the
hash correctly. The server puts the hash in the cookie of a
HelloRetryRequest and sends that to the client. The client
can then put together any ClientHello2 it cares to and
include the cookie from the HelloRetryRequest.
If the server is "stateless" and throws away ClientHello1,
there's no way for it to know that the second ClientHello2
it receives doesn't properly relate to ClientHello1. The
handshake can still go all the way to completion even
with a bad ClientHello2, I think. Also the server can't be
actually stateless since it needs to know the HelloRetry-
Request message for the transcript hash, right?
There are a number of changes allowed to be made to the
ClientHello1 that will make it impossible for the server to
recreate the hash sent in the cookie field, even when there
is nothing malicious happening. Simply changing the
padding extension is one of them. Pruning the key_share
list is another, as is updating the pre_shared_key list. So it
can't reject any ClientHello2 which it doesn't hash to the
cookie value.
I don't know what the implications of this are (I've only spent
about 30 minutes reading the spec.) but there appears to be
some room for mischief if a server is "stateless." Maybe this
should not be allowed out of prudence? What does this mean
for DTLS 1.3?
Putting a pseudo-session-ticket in the cookie as NSS (?) does
might solve this problem to some extent, but I doubt the
extra processing is worth the tiny amount of memory saved
by tossing the ClientHello1 under normal conditions. (When
being actively attacked this may be necessary, though I don't
have experience working in a data center so I can't really say.)
However, the RFC should probably not be implying that you
can do stateless HelloRetryRequest by sending a cookie with
just a hash of ClientHello1 (even if the server uses some
integrity protection mechanism on the hash value).
Mike
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
