As background, the NIST Concat KDF was chosen over the TLS 1.2 PRF because it was already specified for use with key agreement in XML ENC, whereas the TLS PRF is a one-off. It was thought that, particularly for key agreement, libraries were more likely to support key agreement using Concat than a custom KDF, making JWE implementations easier. The authors also decided that it made sense to use the same KDF both for key agreement and to derive CEK and CIK values from a CMK value, to make life easier for implementers. Hence, the use of Concat for both use cases. You wrote that "it demonstrably doesn't meets Concat’s security design (e.g. JOSE can derive the same key for diff user ids as JOSE can omit the ids from the calculation)". It's true that JOSE could derive the same key for different users, but only if the two users use the same CMK value, which the spec requires to be randomly generated for each interaction. If an implementation is repeatedly generating THE SAME 256 or 512 bit random numbers, I suspect it has bigger problems than the ones we're talking about. I'll also point out that draft-mcgrew-aead-aes-cbc-hmac-sha2 puts all its eggs in the basket of the random number generator, and you seem to be in favor of that. By using Concat without PartyUInfo and PartyVInfo fields, we'd be no worse off than mcgrew. As for me, I'd be perfectly happy to change the drafts to say something like "a KDF based upon the Concat KDF" (or to not mention Concat at all), drop the PartyUInfo and PartyVInfo parameters and be done with it. The TLS PRF doesn't use them and it seems to be fine. It doesn't sound you like them either. Might that be a resolution to this whole long discussion? My only worry is that we might get push-back from the security community as a result. Feedback from others would be appreciated. Thanks,-- Mike P.S. The AlgorithmID/PartyUInfo ambiguity you describe is not possible because the only two "enc" values that use Concat in this way are "A128CBC+HS256" and "A256CBC+HS512". It truly is fixed length. The behavior of other "enc" values are beyond the scope of this particular discussion. > From: [email protected] > To: [email protected]; [email protected] > Date: Mon, 12 Nov 2012 10:45:32 +1100 > Subject: Re: [jose] NIST Concat KDF > > 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 > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
