Re: [TLS] ESNI and padding

[Stephen Farrell <[e-mail]>]

Hiya,

On 20/06/2019 02:17, Eric Rescorla wrote:
> I am not in favor of these changes.  They reduce protocol flexibility for
> servers

I don't see being asked to configure a new thing that has
subtle relationships with other things that aren't always
under the control of one entity as "flexibility." I see
that as a burden, and maybe as a protocol design bug.

> which know what they are doing and largely can be implemented in the
> protocol
> by servers which do know what they are doing.

That kind of anthropomorphism often seems to me to indicate
a weak argument:-) Servers don't "know" anything - the question
is whether the current setup could cause problems for a range
of possible deployments, and I think it could if there's less
tight coupling between how ESNIKeys get generated and published
and how names and certificates are handled. IIUC that kind of
setup does exist in the wild.

To give an example, say some hoster is doing ESNI and has set
padded_length to 55. If a new customer turns up with a 56 octet
name, then that hoster has to unexpectedly touch ESNIKeys or
deal with possibly weird ESNI problems for at least a TTL. If
we had an algorithmic approach it should just continue to work.

Characterising that hoster as "not knowing what they're doing"
seems to me wrong. I think that'd be more a case of us not
knowing what we're doing:-)

As to the specific numbers in my mail - I don't much care
what's picked, and do agree that some measurements would help
pick good numbers. I also agree that CertificateVerify is much
less of a concern in reality. But asking that Certificate be
padded "such that its length equals the size of the largest
possible Certificate (message) covered by the same ESNI key"
would in some cases require a new database search for each
TLS session. And since the Certificate message is the path
and not one certificate that could be quite expensive to
impractical depending how a server stores/builds paths. I
also believe that some openssl deployments do this via
locally implemented callbacks so it'd be hard to know how
badly or not the current approach might affect those.

Cheers,
S.