Hiya, On 22/10/2019 04:27, Ben Schwartz wrote: > Note that the current text in the editors' draft says that when > applying GREASE, "The padded_length value SHOULD be 260 or a multiple > of 16 less than 260.". We don't need GREASE to send 260 all the time, > and the draft doesn't recommend it.
ISTM that GREASE needs to follow the kinds of lengths used in practice to be most useful, so if 260 does get widely used, then I guess that's what'd be most useful to GREASE. > Personally, I expect that 260 will be rare for real deployments, > because most systems serve a fixed, known set of domains, and those > that serve a large, dynamic set probably already impose a tighter > length limit. I don't know of any hoster or service with such a name length limit. Do you have any example where a DNS name that can be published and used as a TLS SNI would be declined by a service provider? > > One intriguing alternative would be to define some ESNI ciphersuites > that encrypt a strong hash of the name. Then a server with a large > but finite name database can choose one of these ciphersuites, > pre-compute hashes for names when entering them into the DB, and > quickly invert incoming hashes with a DB lookup. I wouldn't want to > make this the only option because it can't support true wildcard > servers, but I think it would cover most potential users while > limiting the length to 32 octets or similar. Yeah, that'd be nice but as you say doesn't work well for wildcard certs, which I think is a showstopper. I do think there are other algorithmic options we could go with though, that would work. Cheers, S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
