Re: [jose] NIST Concat KDF

["Manger, James H" <[e-mail]>]

Mike,

> By adding the length prefix to the PartyUInfo and PartyVInfo values, I fail to see how the JoBethAnne ambiguity could remain possible.  I addressed that per your earlier note in the -07 drafts by adding the length prefix.

The JoBeth/Anne vs Jo/BethAnne ambiguity is solved. An AlgorithmID/PartyUInfo ambiguity remains. It feels more theoretical, but it simply does not need to exist. The following 2 JOSE messages produce the same KDF input. They shouldn't. It is the sort of situation NIST Concat KDF is specifically designed to avoid.

  {"alg":"A128CBC+HS256\u0000\u0000\u0000\u0007X", "epu":"Jo", "epv":"BethAnne"}

  {"alg":"A128CBC+HS256", "epu":"X\u0000\u0000\u0000\u0002Jo", "epv":"BethAnne"}  


> You wrote that the AlgorithmID doesn’t have a length prefix.  That’s true.  The Concat definition allows fields to not contain a length prefix when they are fixed length, as AlgorithmID is in this case.

AlgorithmID includes the value of the "enc" field, which is hardly fixed length.



> You wrote “Can’t the spec just do what NIST 800-56A says if it really wants to use it?”.  I suspect that underlying this comment is the actual difference you have with the specs’ use of Concat.  It’s not a goal of JWA to make it possible to use every feature of Concat. (Concat isn’t an end unto itself.)  Hence the spec not needing to use SuppPrivInfo, etc.

I have no desire to use SuppPrivInfo. I am completely fine with JOSE saying it must be omitted. I don't really even want to use PartyUInfo and PartyVInfo. NIST 800-56A Concat KDF, however, is designed to ensure the same key cannot be derived if the algorithm, the id of either party, or any other important detail of the context is different. If JOSE says it uses Concat it needs to deliver these properties. If JOSE does not need these properties then it shouldn't falsely imply it achieves them by saying it uses Concat.


> The actual goal is generating two high-quality keys from the CMK.

Great. Then drop the apu/apv/epu/epv stuff and don't call it NIST Concat.


> As for whether we use Concat twice to generate two keys with different inputs and then discard the random value or whether we use Concat once to generate a long enough output to chop it into two keys, that seems like a distinction without a difference.

It probably is a distinction without a difference. So why do you bother making the distinction from the NIST Concat KDF that JOSE says it uses? That just unnecessarily raises a shadow of doubt.


> I reviewed this decision with Jim Schaad a while back, among others, and they concurred.  The precedent for this is the TLS PRF KDF [RFC5246], which generates keys in this manner.

Then use the TLS 1.2 PRF, instead of NIST Concat.


> Unless there’s an actual security argument that this (widely used) practice is demonstrably unsafe, there doesn’t seem to be a reason to change.

JOSE says it uses NIST Concat; it demonstrably doesn't meets Concat’s security design (eg JOSE can derive the same key for diff user ids as JOSE can omit the ids from the calculation); so there is a reason to change.


> I’m trying to have us not lose sight of the fact that a core goal of the JOSE specs is to create specs that are simple enough that they will actually be implemented and used.

Sounds like a good reason not to pick NIST Concat, which chooses more complexity for security in some corner cases.

--
James Manger