On 10/3/20 16:12, Nick Lamb wrote:
You can't possibly implement [stateless HelloRetryRequest] the
way the spec suggests with just a hash in a HRR cookie extension.
Lots of people have and it works just fine, so it seems to me that "You
can't possibly" here means something closer to "I still don't
understand how to" and as such would be more appropriate to some sort
of programming Q&A site like Stack Overflow than an IETF working group.
StackOverflow has only one result if you search for HelloRetryRequest
and it is about jdk.disabledAlgorithms.
When you say it "works just fine" I think you are saying that the
handshake will complete. But is it secure? This is the important
parts of "works" and I'm not sure it's possible to do it correctly
without a lot of work, and am certain that a hash is not enough
information even if it's integrity-protected.
The client MUST use the same value for legacy_session_id in its retried
ClientHello. As a result this value will be available alongside the
cookie.
Section 4.4.2 is clear that a hash used this way in the cookie should be
"protected with some suitable integrity protection algorithm". For
example some implementations use an HMAC construction, but you could do
other things here successfully. So in fact this is not especially
optimistic.
All the integrity protection bytes tell you is that the server did in fact
generate the cookie at some point in the past. You don't even know
how old the cookie is if it just contains a hash, unless you are
frequently changing the key (and keeping the previous key around for
a bit to cover the case that the key rollover happened within the life-
time of an old cookie). A client could possibly exploit this by making
many connections and sending a second ClientHello on each one with
the same legacy_session_id_echo and cookie. A stateless server might
not be keeping track of whether a cookie is being reused, and why
would it if it's actually stateless? If it's going to go through the
trouble
of keeping track of previously-used cookies, possibly across several
distributed machines, why not just be not-stateless and avoid all of
the hassle?
And, yes, it is optimistic to trust a client to do the right thing. It's
also
dangerous. I used the word optimistic to downplay the significance.
Rebuilding the beginning of the transcript hash based solely on what
the client sends in its second ClientHello message is fraught with peril.
Mike
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
