Re: [TLS] ESNI interoperability questions

[Rob Sayre <[e-mail]>]

On Sun, Oct 27, 2019 at 8:46 PM Rob Sayre <[e-mail]> 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