Being totally indistinguishable is probably impossible, but all else being equal more resistance is better than less, no?
Regards, Jonathan On Wed, 17 Feb 2021 at 17:41, Carrick Bartle <cbartle...@icloud.com> wrote: > 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> > 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 > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
