Numerous ways a client can "stick out" have been identified, to the point where it's trivial to block connections using real ECH, regardless of the length of the config_id, which was why I thought we'd largely dropped the attempt not to stick out.
> On Feb 17, 2021, at 8:35 AM, Jonathan Hoyland <jonathan.hoyl...@gmail.com> > wrote: > > 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 > <mailto: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 > > <mailto: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 <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > _______________________________________________ > 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
