I know that ECH doesn't provide security against probing attackers, but such an attacker could easily maintain a list of active keys, and drop connections using them. If the key ID is very long, this would be highly effective at allowing grease ECH connections, but blocking real ECH connections.
An adversary using this strategy against a one byte id would have high collateral damage, but against an eight byte id would virtually none. Providing some resistance to probing adversaries is a nice-to-have, even if we can't provide complete protection. My preference would be for a shorter id. Regards, Jonathan On Wed, 17 Feb 2021 at 16:25, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > On 17/02/2021 16:00, Eric Rescorla wrote: > > On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > > >> > >> > >> On 17/02/2021 00:34, Eric Rescorla wrote: > >>> How is it any harder to manage a multi-octet server-chosen value than a > >>> single-octet server-chosen value? > >> > >> Easier for the library on the server side. If it's >1 octet > >> then someone will want some semantics. If ==1 then they'll > >> have to accept none and possible collisions so it can be > >> handled independently inside the library. > >> > > > > The server is free to enforce 1 byte. > > A server operator would be free to do that. The person > writing the code likely would not be as some server > operator would also be free to try impose semantics > on a multibyte field. > > S. > > > > > > -Ekr > > > _______________________________________________ > 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
