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

[Rob Sayre <[e-mail]>]

On Mon, Oct 21, 2019 at 11:09 AM Eric Rescorla <[e-mail]> wrote:

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

I have not tested this, but I wondered about IDNA-encoded domain names as I
read. Is their encoded form always under 255? So, it might be
worthwhile for the draft to explain where 260 came from.



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

I thought the "padded_length" field might be more useful as a minimum. I
agree with you about narrowly-padded messages.


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
>

I don't agree with this. These questions all concern MUST or SHOULD
requirements in the draft. There should be rationales for the requirements
that aren't obvious. Especially the "SHOULD" ones.

thanks,
Rob