On Tue, Mar 21, 2017 at 2:45 AM, Ilari Liusvaara <[email protected]> wrote:
> What is the correct HkdfLabel for Derive-Secret(foo, "bar", "") in > TLS 1.3 draft-19? > > I ask, because I ran into interop problems because of this, between my > implementation and OpenSSL, and I traced it to this. > > Let's assume PRF-hash is SHA256 (32 bytes output) > > I interpret the spec so that the HkdfLabel is: > > 00 20 0C "TLS 1.3, bar" 00 > > That is, 32 bytes output, 12 byte raw label "TLS 1.3, bar" and > 0 byte context. > > OpenSSL seems to interpret it as: > > 00 20 0C "TLS 1.3, bar" 20 e3 b0 c4 42 98 fc 1c 14 9a fb f4 c8 99 6f > b9 24 27 ae 41 e4 64 9b 93 4c a4 95 99 1b 78 52 b8 55 > > Where the e3b0c442... bit is the SHA-256 hash of empty string. > > That is, 32 bytes output, 12 byte raw label "TLS 1.3, bar" and > 32 byte context, holding SHA-256 of empty input. > > > Which is correct? Or neither? > I believe that OpenSSL is correct. Note that this construction already appeared in the computation for the binder keys in -18 and I believe that everyone interpreted it as the hash of the empty string. I think that's more natural given the notation, because Derive-Secret explicitly hashes the input, whereas HKDF-Expand-Label is defined as using "" = means a 0-length hash. If people think we should adopt your interpretation, I think we would need to special-case the notation, which of course isn't the worst thing in the world. Maybe we should update the draft, though. -Ekr > > > -Ilari > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
