KDF JEP for the Java Platform

Wed Mar 20 02:24:42 UTC 2024

Hi Kevin,

I implemented a prototype for HKDF derivation with SunPKCS11. This was 
tested with the NSS Software Token v3.90, both in FIPS and non-FIPS 
configurations. Testing includes the 7 vectors in RFC 5869 (*), 
derivation of a DH base key, derivation of a ECDH base key and use of 
derived keys for Cipher and Mac services. In each case I did key and 
data derivation under the following modes: extraction-expansion, 
extraction and expansion. All of this should be enough coverage of TLS 
1.3 key derivation. I'll adjust this prototype to the final API —once we 
have it— and make a proposal.

I would like to add two more pieces of feedback from the SunPKCS11 side:

For TLS 1.3 derivation, it would be desirable to handle the salt as a 
Key object in the HKDFParameterSpec (instead of a byte[]). The TLS 1.3 
key schedule [1] takes the salt from a previous key derivation —so it's 
naturally a key—, except for the Early Secret where it's all 0's. For 
SunPKCS11 this has 2 concrete benefits: 1) we don't need to re-build the 
salt as a key each time and 2) we can operate in FIPS-compliant mode.

Different implementations of the API may need similar consistency checks 
over the derivation parameters. Would be good if these checks are done 
at HKDFParameterSpec construction time. For example, output length has 
to be greater than 0.

Regards,
Martin.-

--
(*) Vector #1 does not work in FIPS mode because the salt's length is 
too small.
[1] - https://datatracker.ietf.org/doc/html/rfc8446#section-7.1

On 7/20/23 16:05, Kevin Driver wrote:
> As a newly minted committer and Oracle employee tasked with the 
> following, I thought I should send an introductory mail to the list and 
> start a discussion on adding a standard API for key derivation functions 
> (KDFs) to the Java Platform. You may have noticed the KEM [1] APIs and 
> associated implementation coming in JDK 21. KDF [2] is another building 
> block in support of HPKE [3] (which requires KEM and KDF as 
> dependencies/primitives). HPKE will become important during the 
> transition to post-quantum cryptography.
> 
> The concept of a KDF implementation within the security libraries is not 
> entirely new (a JEP was put forth previously but withdrawn [4]); however 
> it is time to formalize an API, add some additional implementations, and 
> make some older implementations available for use in a more standard way.
> 
> We look forward to your feedback on the below proposal and would be 
> interested in any thoughts on the design considerations listed at the end.
> 
> To wit, I’ll try to give a brief overview of the following:
> 
> - high level design
> - current status
> - design considerations
> 
> **High Level Design**
> 
> In general, this diagram encapsulates a lot of our intended trajectory 
> (see attached diagram).
> 
> The new KDF APIs will serve as an umbrella over an RFC 5869 [5] 
> implementation of HKDF, existing PBE implementations, and future 
> implementations. However, our current plans are to allow algorithms, 
> such as PBE, to continue to be accessible in the manner they are today 
> (with possible deprecation at some point in the future).
> 
> In addition, JSSE has a “sibling” implementation of something very 
> similar to RFC 5869 (but perhaps somewhat specialized for the JSSE 
> use-cases), so it will likely be merged into the “proper”/main RFC 5869 
> implementation and called/utilized in a fashion similar to how JSSE does 
> today. One goal is certainly to be minimally disruptive to JSSE 
> implementation code where possible, so as to not incur a massive 
> retesting/validation effort for TLS.
> 
> Also related to JSSE, one of the reasons for the Tls* classes (mentioned 
> in the SunJCE provider) being located in restricted packages, I’m told, 
> is because there was not yet a KDF API available. The classes described 
> are in:
> 
> • sun.security.internal.interfaces
> • sun.security.internal.spec
> 
> A side-goal/benefit of this work will be to relocate the above classes 
> out of their restricted packages (ie - not in sun.security.internal any 
> longer).
> 
> **Current Status**
> 
> Currently we (Oracle) have a set of KDF framework APIs as well as an 
> implementation of RFC 5869 and a TLSPrfKDF implementation, which were 
> developed previously but not yet made available. I have taken up this 
> work, and I’m working through suggested modifications and/or 
> improvements. There are, however, a few ongoing points of discussion, a 
> couple of which I will be bringing forward today.
> 
> **Design Considerations**
> 
> • What, if any, JSSE implementations are there outside of Oracle which 
> might be affected by the choice to relocate the Tls* classes from their 
> SunJCE restricted packages? We are interested in speaking with those 
> affected by this potential change.
> • APIs in JCE have historically been “multi-phased” (ie - Cipher’s init, 
> update, doFinal). However, it is also somewhat en vogue to lean toward 
> immutability as much as possible. We’re weighing the relative merits of 
> a “one and done” style API with lots of parameters vs a more 
> “traditional” multi-phased approach.
> 
> [1] https://openjdk.org/jeps/452
> [2] https://en.wikipedia.org/wiki/Key_derivation_function
> [3] https://www.rfc-editor.org/rfc/rfc9180.html
> [4] https://bugs.openjdk.org/browse/JDK-8189808
> [5] https://www.rfc-editor.org/rfc/rfc5869.html
> 
> I will followup in a few weeks with more detail and will look forward to 
> your feedback in the meantime. Thanks for your interest/participation!
> 
> Kevin Driver
> Mobile: +1.512.431.5690
> Java Security Libraries
> 
> 
> 