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
