Oh, that is a good observation. If the client has the same ServerHello-sensitive preferences (version, key share, supported groups, cipher suites, PSKs) between inner and outer ClientHello, it doesn't need to reprocess. But if it has different preferences, it needs to resolve this circular dependency. Most of the ServerHello-sensitive preferences are actually currently required to match, otherwise HRR doesn't work, but hopefully we'll fix HRR and remove this awkward restriction. But the key word is *most* because PSKs do differ between the two. It would be weird if the client could be tricked into completing an outer ClientHello handshake with an inner ClientHello PSK. I suspect it's "merely" weird, but we should not so easily get implementations into self-inconsistent states.
The stuff in ServerHello is sufficiently constrained that this is probably not fatal. Realistically, the two handshakes are sufficiently intertwined on the client at this point that it'll probably need to be careful about the inner/outer point regardless. But I agree it's not great and worth looking at again. I think the mechanism in https://github.com/tlswg/draft-ietf-tls-esni/pull/287 did not have this circular dependency, but it was introduced in https://github.com/tlswg/draft-ietf-tls-esni/pull/353. I forget, did we need to bind it to the actual handshake secret, or was the transcript and ClientHelloInner.random sufficient? That would avoid the circular processing dependency. David On Tue, Mar 16, 2021 at 10:06 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hi all, > > I raised a github issue [1] related to (but different from) > this but would prefer a discussion via email if that's ok. > Depending how this goes, I can create a new GH issue I guess. > > ECH draft-09 (and -10) requires the client to verify that the > server has processed ECH by comparing 8 octets in the > ServerHello.random with a value one can only know if you know > the inner CH octets and (pretty much all) the rest of the > h/s so far. That seemingly removes the need for the client to > maybe decrypt twice (once based on inner CH, once based on > outer) to see what works. That can be implemented ok for > the nominal case. As far as I can see that was the result of > github issue #274 [2] back in Aug/Sep 2020. > > But in error cases that seems to require the client to > possibly process the same ServerHello extensions twice, > which could have side effects, is generally ickky and > I think shows that this aspect of the design maybe needs a > change. That's not much different from trial decryption > really. In my current, (and still horrible;-), OpenSSL code > the minimal effect is memory leaks for error cases that are > tricky to handle, but can be handled, although at the expense > of probably making the code even more brittle. (Note: I'm > neither defending nor attacking the way OpenSSL handles > extensions here:-) > > The specific problem is one needs the handshake secret to > calculate the 8 octets one expects in the ServerHello.random, > but generating the handshake secret typically involves a key > share ServerHello extension and might in future involve some > PQC stuff, so I think we can't say for sure which subset of > extensions are needed for the calculation. And if the first > time doesn't give the right answer (e.g. if the client used > the wrong ECHConfig) then you gotta process the ServerHello > incl. its extensions a 2nd time. > > I think the requirement we ought try meet here is that any > confirmation value needs to be something the client can > calculate using values known before the SH is rx'd plus the > ServerHello as a (mostly) unprocessed buffer. That could be > e.g. some hash of the encoded inner CH, ECHConfig and the > ServerHello maybe. Some of those issues were discussed in [2] > already and in an interim meeting I missed but I reckon it > might be worthwhile thinking again. > > Thanks, > S. > > [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/399 > [2] https://github.com/tlswg/draft-ietf-tls-esni/issues/274 > > > > _______________________________________________ > 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
