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

[Rob Sayre <[e-mail]>]

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

>
>>
>> I hadn't seen the fixed-but-variable length construction that the "zeros"
>> field uses before (although I haven't written much TLS code).
>>
>
> It is used in other places. See, for instance:
> https://tools.ietf.org/rfcmarkup?doc=8446#section-5.2
>

Ah. I have only worked on some handshake messages, and it was new to me. In
the future, I think it might be worth calling out this kind of field as a
distinct type. Maybe "dependent vector"? The TLS 1.3 RFC does say "The size
of the vector may be specified at documentation time or left unspecified
until runtime", but I thought the latter part of that sentence was
referring to variable-length vectors.



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



> This part of the spec is also just generally difficult to follow, in my
>> opinion. I had no trouble following the ESNIKeys section. Perhaps the
>> problem is in the interaction of prose order, serialization order, and
>> procedural code order.
>>
>
> Well, this structure is likely to change a fair bit, so probably not worth
> trying to update the text right at this moment.
>

Fair enough. I would also suggest making sure that this section does not
span a page boundary. That made things worse for me.

thanks,
Rob