Mike, The server receives a ClientHello from a prospective client. In the case of DTLS and QUIC, this path has not yet been validated, so the server may want to verify the remote address prior to continuing the handshake. This is incredibly important as generating key_shares and signing the transcript are not trivial operations and make for a very easy DDoS attack.
The server hashes the ClientHello message and generates a random cookie. In a connection-oriented setup, the cookie is just a random challenge. In a semi-stateful environment, there's a lookup table from the cookie to the ClientHello hash and no other state is stored. In a stateless environment, the cookie might be an encrypted payload, containing the ClientHello hash plus any additional information. This is primarily designed with load balancers in mind. The connection is validated by front-line load balancers that mitigate DDoS attacks and distribute "safe" connections to backend servers. These load balancers deal with an enormous amount of traffic and must be simple: 1) reply to ClientHello messages with a HelloRetryRequest and 2) assign and forward valid ClientHello retries to a backend server. The original ClientHello does not need to be stored, as the HRR contains the information required to continue the handshake. The backend service can use the cookie to either lookup the CH hash in a shared database, or even better decrypt the cookie using a shared secret to get the CH hash. Now the handshake can be completed like normal. I definitely agree that the benefits of HRR are not made obvious in the RFC and I thought it was weird too. I wouldn't have hashed the hash of the ClientHello, but it makes sense given most languages don't allow storing the state of a hash. The design decisions make sense for services at scale and require minimal effort for hobby TLS 1.3 implementations (including mine). On Sat, Oct 3, 2020 at 2:05 PM Michael D'Errico <mike-l...@pobox.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
