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

Reply via email to