Re: [TLS] ESNI and padding

[Eric Rescorla <[e-mail]>]

On Thu, Jun 20, 2019 at 1:20 AM Stephen Farrell <[e-mail]>
wrote:

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

Well, opinions differ, I suppose. The server implementor is free to
implement the policies you suggest here.

> 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:-)


I'm assuming this is just snark, not something you think has any
rhetorical force.


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

And as I said, the hoster is free to implement that value themselves. But
I'm not in favor of opposing them.


> 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:-)
>

Again, I suppose opinions differ.

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.

-Ekr

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