This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The resolution for Bug 24838 attempted to resolve the inconsistencies in HKDF-CTR by formalizing on SP 800-108, rather than RFC 5869. However, this failed to capture several points from the discussion, and now this creates a real risk of incompatibilities: 1) HKDF as a name specifically refers to RFC 5869. - Jim raised this point during the discussion, and Vijay agreed to this in http://lists.w3.org/Archives/Public/public-webcrypto/2014Feb/0181.html 2) RFC 5869 and SP 800-108 are incompatible 3) Our specification does not impose limitations on how Label is encoded, creating opportunities for a Null-Byte to be encoded in the Label and thus confused with context (see http://lists.w3.org/Archives/Public/public-webcrypto/2014Feb/0186.html for discussion) I think this is a spec blocker, because if there are any implementations of this function using the HKDF-CTR name, we will create real risks of incompatibilities with "other" HKDF implementations. Suggestion: 1) Introduce HKDF as an algorithm based on RFC 5869 2) Rename the existing HKDF-CTR algorithm name to SP800-108 2.a) Clarify the existing ambiguities (with suitable review)
It seems to me that unless there is a real use-case for SP800-108 rather than RFC 5869, then RFC 5869 should be specified clearly in the text and the text of the algorithm rewritten accordingly. The test-suite should only test RFC 5869 so thus, incompatibilities can be detected during the CR test-suite interop phase.
I am not aware of any applications that are using the NIST version of HKDF rather than the IETF version. CONCAT is the NIST KDF function that people refer to. The issue raised in point 3 is not an issue for the IETF HKDF function as the salt and info fields are used in different locations and are not concatenated together. (Even for the NIST case there is nothing wrong with the label containing a null character if it was length prefixed or of a known fixed length). I would also vote to make this be the IETF version and start forgetting that NIST has done this. The IETF version is cleaner, better designed and has better security proofs.
This bug has been moved to the web crypto github repository, with the proposed resolution to reference RFC 5869 https://github.com/w3c/webcrypto/issues/27