On Mon, Oct 21, 2019 at 7:41 AM Eric Rescorla <[email protected]> wrote: > > > On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre <[email protected]> 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
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
