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

[Ben Schwartz <[e-mail]>]

On Tue, Oct 22, 2019 at 4:21 AM Stephen Farrell
<[e-mail]> wrote:
>
>
> 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.

Agreed.  (Although the details of this are potentially tricky, like
whether the random length can be sticky without accidentally labeling
the user.)

> > 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?

Sure.  For example, tumblr limits usernames to 32 characters:
https://unwrapping.tumblr.com/post/58535402323/tips-tumblr-username

These usernames also form the subdomain part of the *.tumblr.com
wildcard, so the longest allowed name is [32 chars].tumblr.com.

I expect that most wildcard TLS hosts impose similar limits.

> > 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 don't think it's quite that bad.  For example, this approach would
work fine for tumblr in principle.  Any hash corresponding to a name
that exists can be inverted from their database.  Any hash
corresponding to a name that doesn't exist will return the default
cert, which still covers *.tumblr.com.

The case where this doesn't work is when multiple wildcard domains
share an IP but not a certificate.  That seems most likely in a CDN
context, where multiple wildcard customers could be sharing an IP and
providing their own certificates.  If the CDN's operational
architecture allows pushing all wildcard customers into a single
certificate, the limiting factor becomes the number of names allowed
in one certificate.

> I
> do think there are other algorithmic options we could
> go with though, that would work.

I suppose a server could indicate that the first N labels be included
verbatim, and the remainder should be hashed.  Or maybe it should only
be hashed if it's longer than the hash size ... there are all sorts of
options here.

>
> Cheers,
> S.
>
>