Re: [TLS] ECH/ESNI - is accept confirmation calculation brittle in the face of errors?

[Stephen Farrell]

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

circular processing dependency.

the transcript and ClientHelloInner.random sufficient? That would avoid the

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.

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.

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.

-- Christian Huitema



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys

OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls