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

On Tue, Oct 22, 2019 at 7:54 PM Rob Sayre <sayrer@gmail.com> wrote:
>
>
>
> On Tue, Oct 22, 2019 at 7:29 PM Salz, Rich <rsalz@akamai.com> wrote:
>>
>>
>>
>> Low numbers might encounter all sorts of well-known cryptographic problems, and varying the padding of the domain name with any granularity would tend to narrow the search space for an attacker.
>>
>>
>>
>> What well-known cryptographic problems?  Varying the padding can also *add* security because foo.secret.example.com could show up with two different sizes.
>
>
> Hi Rich,
>
> To be clear, I am in favor of varying padding. I want the "zeros" field to have a prefix and I want my client to do whatever it wants with that buffer, within the boundaries of an unsigned 16 bit integer.
>
> I was concerned about a couple of different issues. The first is that the search space for the plain text is actually quite restricted. For example, "foo.example.com" might only vary by three characters vs other "example.com" domains. So, 16-character padding boundaries might be an issue.
>
> The other is that I worried that an attacker could use brute force to replicate traffic, and thus determine what was requested. I couldn't come up with a way to do this easily, but I did worry that a small search space in the SNI text would make it easier.
>
> And, as I wrote, I am not an expert in these matters. From what I do know, I think padding the buffer to the maximum likely size seems like a good idea.

Padding to the max every time leaks no information. It also doesn't
have some of the operational issues. There are possible setups on
Cloudflare where Cloudflare will not know what domains are being
proxied ahead of time (wildcard DNS+wildcard cert,
https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DNS-FAQ#CloudflareDNSFAQ-DoesCloudflaresupportwildcardDNSentries
available to enterprise customer)

What's not clear is what the other proposals leak. Some of them like
randomized padding end up leaking much more the might be expected.

At the same time Client Hello sizes aren't constrained to be tiny, but
the next problem of 1280 bytes is not that far off either. So we
should be judicious in spending those bytes.

>
> thanks,
> Rob
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
"Man is born free, but everywhere he is in chains".
--Rousseau.