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 does end
up being easy to implement, because "realSNI" is placed at the end of
ClientESNIInner. However, this detail was not obvious to me until I got
through all of the serialization code I was writing, and it would also seem
to limit the places PaddedServerNameList should appear in TLS structs.
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.
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.
thanks,
Rob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
