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

[Rob Sayre <[e-mail]>]

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

>
>
> On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre <[e-mail]> wrote:
>
>
>
>> Judging by the mailing list archives, the design of the field is
>>>> intentional. It's not clear to me why "zeros" wasn't specified as
>>>> variable-length with a prose restriction, though.
>>>>
>>>
>>> Because then you have a spurious length field.
>>>
>>
>> I don't understand why it would be spurious. In this case, the
>> deserializing implementation needs to inspect every byte anyway.
>>
>
> Because if you set padding to be the length of the maximum value, then a
> length byte makes every message one longer.
>

Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you
just mean it would be superfluous. That could be true, but it is dependent
on the value of a field in a DNS record. If it had a length, I could have
used existing payload deserialization code.

Having gone through every message in this draft, I don't understand the
rationale behind the following section and the corresponding
PaddedServerNameList:

"
...
CipherSuite cipher_suites<2..2^16-2>;
uint16 padded_length;

...

padded_length : The length to pad the ServerNameList value to prior
   to encryption.  This value SHOULD be set to the largest
   ServerNameList the server expects to support rounded up the nearest
   multiple of 16.  If the server supports wildcard names, it SHOULD set
   this value to 260."

That's not to say the draft is wrong, but the rationale seems missing. The
rationale may exist in a mailing list message or github issue.

thanks,
Rob