On Fri, Nov 1, 2019 at 4:04 PM Eric Rescorla <e...@rtfm.com> wrote: > > > On Fri, Nov 1, 2019 at 3:54 PM Rob Sayre <say...@gmail.com> wrote: > >> >> >> On Fri, Nov 1, 2019 at 3:39 PM Eric Rescorla <e...@rtfm.com> wrote: >> >>> >>>>> >>>> I see. But is there any reason to make these inputs predictably zero by >>>> spec? >>>> >>> >>> Absent some reason not to, this seems like a reasonable design choice. >>> At minimum, it has the advantage that it's easy to detect some classes of >>> implementation errors. >>> >> >> I don't think the current spec is a good idea. It mandates padding with >> zeros, and lets servers dictate a length. I think the client should dictate >> the length, at least. >> > > This is a separate issue from the structure of the padding. >
I think the length of the padding might be fairly considered part of the "structure of the padding". > > > >>> I wouldn't exactly call that misreading. >>>> >>> >>> This seems like a definitional question that is not worth debating. >>> >> >> Hey now, you're the one that wrote "misreading" initially. If "additional >> data" is not what's used as "additional authenticated data" in the end, >> fine. >> > > NSS does not include the leading 0s as part of the computation of the AAD > that appears on the wire. To the extent to which you may have believed > otherwise based on your reading of the code, that is not a correct > understanding. > I see, so I should chase down every last obfuscated padding byte? I can't actually read a draft to implement this spec. I also do not think this issue should have been unilaterally closed: https://github.com/tlswg/draft-ietf-tls-esni/issues/190 Maybe it's time for some new TLS editors. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
