Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <BAY171-W792A9B319A442E04BB424DB76D0@phx.gbl>
Date: Mon, 12 Nov 2012 22:02:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <DBECB571-B91A-49EB-A125-842C988A4F25@bbn.com>
References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com>,
 ,
 <CE8995AB5D178F44A2154F5C9A97CAF40252198DCF55@HE111541.emea1.cds.t-internal.com>,
 ,
 <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com>,
 ,
 <CE8995AB5D178F44A2154F5C9A97CAF40252199B9114@HE111541.emea1.cds.t-internal.com>,
 , <BF7E36B9C495A6468E8EC573603ED94115076832@xmb-aln-x11.cisco.com>, ,
 <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com>,
 , <CAHcDwFwAD-EJBytkYE0q0GPZduKJUnvO8s69wTbZjZt2Cgo+Lg@mail.gmail.com>, ,
 <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com>, ,
 <255B9BB34FB7D647A506DC292726F6E115001D5886@WSMSG3153V.srv.dir.telstra.com>,
 <BAY171-W38F4124E87A73E5E84D057B76E0@phx.gbl>,
 <255B9BB34FB7D647A506DC292726F6E11500331F3B@WSMSG3153V.srv.dir.telstra.com>
 <BAY171-W792A9B319A442E04BB424DB76D0@phx.gbl>
To: Michael Jones <michael_b_jones@hotmail.com>
Cc: james.h.manger@team.telstra.com, jose@ietf.org
Subject: Re: [jose] NIST Concat KDF
Precedence: list

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. =20

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


=20


On Nov 11, 2012, at 10:51 PM, Michael Jones =
<michael_b_jones@hotmail.com> 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.
> =20
> You wrote that "it demonstrably doesn't meets Concat=92s 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.
> =20
> 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.
> =20
> Thanks,
> -- Mike
> =20
> 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.
>=20
> > From: James.H.Manger@team.telstra.com
> > To: michael_b_jones@hotmail.com; jose@ietf.org
> > Date: Mon, 12 Nov 2012 10:45:32 +1100
> > Subject: Re: [jose] NIST Concat KDF
> >=20
> > Mike,
> >=20
> > > 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.
> >=20
> > 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.
> >=20
> > {"alg":"A128CBC+HS256\u0000\u0000\u0000\u0007X", "epu":"Jo", =
"epv":"BethAnne"}
> >=20
> > {"alg":"A128CBC+HS256", "epu":"X\u0000\u0000\u0000\u0002Jo", =
"epv":"BethAnne"}=20
> >=20
> >=20
> > > You wrote that the AlgorithmID doesn=92t have a length prefix. =
That=92s true. The Concat definition allows fields to not contain a =
length prefix when they are fixed length, as AlgorithmID is in this =
case.
> >=20
> > AlgorithmID includes the value of the "enc" field, which is hardly =
fixed length.
> >=20
> >=20
> >=20
> > > You wrote =93Can=92t the spec just do what NIST 800-56A says if it =
really wants to use it?=94. I suspect that underlying this comment is =
the actual difference you have with the specs=92 use of Concat. It=92s =
not a goal of JWA to make it possible to use every feature of Concat. =
(Concat isn=92t an end unto itself.) Hence the spec not needing to use =
SuppPrivInfo, etc.
> >=20
> > 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.
> >=20
> >=20
> > > The actual goal is generating two high-quality keys from the CMK.
> >=20
> > Great. Then drop the apu/apv/epu/epv stuff and don't call it NIST =
Concat.
> >=20
> >=20
> > > 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.
> >=20
> > 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.
> >=20
> >=20
> > > 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.
> >=20
> > Then use the TLS 1.2 PRF, instead of NIST Concat.
> >=20
> >=20
> > > Unless there=92s an actual security argument that this (widely =
used) practice is demonstrably unsafe, there doesn=92t seem to be a =
reason to change.
> >=20
> > JOSE says it uses NIST Concat; it demonstrably doesn't meets =
Concat=92s 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.
> >=20
> >=20
> > > I=92m 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.
> >=20
> > Sounds like a good reason not to pick NIST Concat, which chooses =
more complexity for security in some corner cases.
> >=20
> > --
> > James Manger
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose