This argument does not seem terribly convincing. You seem to be missing the importance of re-using things that have been used before in this context.
On the one hand, we invent something new "based on Concat", something which would has not been evaluated and approved for use in any context where that is important. On the other hand, the TLS PRF is very broadly used and trivial to implement. While I don't know he chapter and verse, it seems likely that someone has considered the implications of trying to get a TLS stack approved for use in, say, a Suite B environment. Unless you really want to do the hard work of demonstrating the strength of this new KDF, let's just stick with something we all know. I would be fine with the TLS PRF, or with just using longer keys (McGrew-style). Concat would also be OK, if we did it properly; that just seems to be a bad fit with the JOSE operational model. (BTW: Using the TLS PRF would be a concrete use case for a nonce parameter.) --Richard On Nov 11, 2012, at 10:51 PM, Michael Jones <[email protected]> wrote: > 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
