On 3/18/2021 10:24 AM, Stephen Farrell wrote:
Hiya,
On 18/03/2021 16:55, Christian Huitema wrote:
On 3/18/2021 7:35 AM, Christopher Patton wrote:
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.
As I recall, it was decided to bind the acceptance signal to the
handshake
signal in order to mitigate some specific, active, "don't-stick-out"
attacks.
The specific suggestion to tie the acceptance signal to the handshake
secret was made I believe to simplify the security analysis. There
are a variety of attacks in which a man in the middle can play games
with specific extensions.
I missed the bit that allowed extension-specific games - can
you point me at that?
Tying the signal to the handshake secret provides a robust defense
against such games, and simplifies the analysis of the security
properties. It also has nice 'don't stick out' properties, but those
are not the only reasons.
And one consequence is that you end up doing more or less
all the work of trial decryption to handle the case where
the wrong ECHConfig was used by the client. If we do stick
with wanting that binding then I think it may be cleaner to
actually just do the trial decryption (of an encrypted
extension like the earlier nonce) and then declare victory
or fallback to checking the outer after that - at least in
that case one can expect to be able to use existing code more
easily and with less liklihood of breaking things or leaving
leaks.
I agree that you have a strong argument there, Stephen, one that was not
developed during the discussion on the mailing list and on GitHub. If I
paraphrase, trial decryption has two big components: first computing the
master secret based on the trial hypothesis, and then deriving the
handshake key and verifying whether it actually decrypts the server's
message. You measure that most of the work is done when "computing the
master secret". If the hint depends on the master secret, then there is
little difference in cost between "computing the master secret and
checking the hint" versus "computing the master secret and trying to
decrypt the message". We could just as well do trial decryption.
Well, OK. That's exactly the kind of things that we learn from doing
implementations. That means we should either go for a much simpler hint
of acceptance, or just be happy with trial decryption. There were a
bunch of options reviewed in GitHub issue #274
(https://github.com/tlswg/draft-ietf-tls-esni/issues/274). Should we
reopen that discussion?
Or, and maybe even better, think again about those attacks
and see if they can be avoided without the handshake-secret,
or if they still seem compelling enough to justify the awkward
consequences.
I think that the requirements are to (1) make sure that the hint proves
that the server properly decoded the ECH data and (2) make sure that the
hint is different for every attempt. The embedding in the server random
is probably the only option, given that TLS 1.3 very much restricts the
number of unencrypted extensions in the Server Hello.
Cheers,
S.
PS: An aside - I reckon it's too late to try not stick out
with the server hello - the client hello has given the game
away lready. That's a bummer really but I think it's game-
over for that entry on the wishlist with ECH.
Yes. We have to rely on effective greasing. I don't have a great
confidence in that.
-- Christian Huitema
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
