On Sun, Oct 20, 2019 at 2:41 PM Rob Sayre <say...@gmail.com> wrote: > Hi, > > I was implementing https://tools.ietf.org/html/draft-ietf-tls-esni-02 > (since I believe that version is what Firefox and Cloudflare currently > ship), and I had a difficult time parsing this part of the draft: > > struct { > ServerNameList sni; > opaque zeros[ESNIKeys.padded_length - length(sni)]; > } PaddedServerNameList; > > struct { > uint8 nonce[16]; > PaddedServerNameList realSNI; > } ClientESNIInner; > > 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 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. 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. -Ekr > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
