Not if "more resistence" is still trivial.
> On Feb 17, 2021, at 9:51 AM, Jonathan Hoyland <jonathan.hoyl...@gmail.com> > wrote: > > 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 > <mailto: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 >> <mailto: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 <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