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

[Eric Rescorla <[e-mail]>]

On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre <[e-mail]> wrote:

> On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre <[e-mail]> wrote:
>>
>>> Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you
>>> just mean it would be superfluous.
>>>
>>
>> Yes, that is what I mean.
>>
>
> OK. To be clear, I understand why there is padding in the spec. I don't
> understand three aspects:
>
> 1) Where did the number 260 come from? It also seems to conflict with the
> "multiples of 16" advice in the previous sentence.
>

I believe it was large enough to fit the maximum plausible label size, but
I'd have to go look at the relevant issue.


2) Why does the server set the padding amount? If clients were allowed to
> vary it with different amounts of zeros, wouldn't that be more anonymous?
>

No. You want padding to be set to be the longest size that you would send
to any origin in the anonymity group, and the server knows this. Many
client padding strategies leak information over time and it's hard to know
how to construct one that doesn't unless you know the max. For instance,
consider what happens if the anonymity group consists of "a.example" and "
thisisaverylongname.example.com" and the client always pads to the next 16.


3) Why is the length of "zeros" implicit rather than explicit? Is it to
> save a few bytes, or is there a deeper reason?
>

It saves bytes on the wire. It's also the way we've done other zero padding.


None of this stuff signals a flaw in the draft from an interoperability
> perspective--I was able to follow it as a non-expert in TLS and get things
> working. But I still have questions about why things are specified this way.
>

Generally speaking, these issues were aired on the list or in Github
issues, so the best way to answer them is to go look at the history

-Ekr


> thanks,
> Rob
>