Re: [TLS] draft-ietf-tls-esni feedback

[Stephen Farrell <[e-mail]>]

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.