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. > 3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD >>>> input (<https://github.com/tlswg/draft-ietf-tls-esni/issues/190>) >>>> >>> >>> I believe you're misreading the code. For historical reasons, the >>> internal NSS TLS AEAD API prefixes the AAD argument with the sequence >>> number. When we repurposed this code for ESNI, we just passed in a 0 >>> sequence number. That value is stripped off and is not part of the AAD >>> computation. >>> >> >> I see, so you're saying that NSS adds 8 bytes to the AAD input, and then >> strips it off at some later point? >> > > No. I'm saying that the function argument is called |additionalData| but > that's not what's used as AAD in the actual cryptographic function. > > > 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. > > Maybe something to fix? >> > > This is not on topic for this mailing list. > I think it is, since no one could read any ESNI draft and get the DNS record's checksum right, at the very least. So, there are some issues where it can be hard to tell if the spec is wrong, my implementation is wrong, or another implementation is wrong. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
