On Tue, Oct 22, 2019 at 7:54 PM Rob Sayre <say...@gmail.com> wrote: > > > > On Tue, Oct 22, 2019 at 7:29 PM Salz, Rich <rs...@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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
