Re: [TLS] ESNI and padding

[Stephen Farrell <[e-mail]>]

Hiya,

On 20/06/2019 14:48, Eric Rescorla wrote:
> Again, I suppose opinions differ.

Yep:-)

> 
>> 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.
> 
> I don't really know why you think that.

I've come across openssl mails/github issues (I'd
have to go back and find 'em again though so this
is just from memory) where servers use a callback
to take the SNI value and query a DB to get the
private key and cert to use in the TLS session. If
the current requirement is to be met, such code
would need to change to figure out the max Certificate
message that could be sent in order to pad as per
the spec. If that code only pulls the server cert
from the DB and then figures out what intermediates
to also send in the Certificate message, then
correctly implementing the spec could be v. hard,
and likely wouldn't be done would be my guess. I'd
not be surprised if they just do some other thing
like read a configuration setting or something and
that could be brittle as certs are updated in the
DB with e.g. new X.509 extensions added. I'd imagine
that servers using other libraries may well face
the same issue.

But just to be clear - that's not an end of the
world thing, but if done badly, could leak length
information, so I'd be happy if we could find a
padding scheme that'd be easier to implement in a
library for servers where the set of TLS server
certs isn't a small static set. Hence my suggestion
of padding to some multiple of M which wouldn't
require any new DB lookups or config settings for
that purpose.

Cheers,
S.