On Mon, Oct 21, 2019 at 6:06 AM Eric Rescorla <e...@rtfm.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
