On Sun, Oct 27, 2019 at 8:46 PM Rob Sayre <say...@gmail.com> wrote: > Hi, > > The joke is on me, because medium.com also does not check any SNI / ESNI > field. :) > > However, I did notice that my record_digest value was off vs Firefox. And, > now, I don't feel so bad. > > I noticed that esni-02 and esni-03 defined record_digest as: > > record_digest A cryptographic hash of the ESNIKeys structure from > which the ESNI key was obtained, i.e., from the first byte of > "checksum" to the end of the structure. This hash is computed > using the hash function associated with "suite". > > but, esni-04 defines record_digest like so: > > record_digest A cryptographic hash of the ESNIKeys structure from > which the ESNI key was obtained, i.e., from the first byte of > "version" to the end of the structure. This hash is computed > using the hash function associated with "suite". > > By following the record_digest algorithm from esni-04, I was able to match > Firefox's record_digest fields for a given domain. This strikes me as very > odd, since the ESNIKeys structure changed in esni-04, but I'm still using > the older, esni-02 definition. So, it sure seems like people are running a > strange mix of drafts at the moment. I think there's still something wrong > with my calculation of the encrypted_sni field--perhaps I will have to read > more NSS source code to figure out what that is. :) >
Oh, and sorry for the postscript, but a common piece of cryptographic mythology is that using the same first bytes for every hash input can weaken it. I have never looked into that assertion, and I also haven't looked into whether using a checksum in the way -02 or -03 did could be problem. Why did the draft originally omit the version number, and why does it no longer do that? thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
