Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20190823195357.GE60855@kduck.mit.edu>
Date: Fri, 23 Aug 2019 16:02:20 -0400
Cc: IESG <iesg@ietf.org>,
 LAMPS WG <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F563BF49-DB79-4F87-96B3-497B05332602@vigilsec.com>
References: <156597611893.31967.2500700648100356711.idtracker@ietfa.amsl.com>
 <B73FED9C-8983-4CFE-AD66-E548CEEAD45B@vigilsec.com>
 <20190823020007.GZ60855@kduck.mit.edu>
 <83F03FA0-4AB4-417D-BABA-69C3424474D0@vigilsec.com>
 <20190823195357.GE60855@kduck.mit.edu>
To: Ben Kaduk <kaduk@mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Go2hLgwGwWwbL-ImCAuQg84MY9Y>
Subject: Re: [lamps] Benjamin Kaduk's Discuss on
 draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT)
Precedence: list

Ben:

> On Fri, Aug 23, 2019 at 02:23:14PM -0400, Russ Housley wrote:
>>=20
>>>>> =
----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> =
----------------------------------------------------------------------
>>>>>=20
>>>>> I think we need to have a discussion about the abstract API for a
>>>>> KEY-DERIVATION instance and how that relates to what we need for a =
key
>>>>> combination operation.  In Section 5 we assume that we can use the
>>>>> HKDF terminology, but that doesn't seem to hold universally for
>>>>> KEY-DERIVATION; for example, while HKDF has IKM, salt, and info, =
PBKDF2
>>>>> (from RFC 3211 that AFAICT introduces keyDerivationalgorithm for =
CMS) is
>>>>> specified by RFC 2898 as taking just the input secret (password) =
and a
>>>>> salt, with no separate 'info' (and of course the different =
iteration
>>>>> count and PRF parameters needed for its construction).  I note =
(with
>>>>> chagrin, as sponsoring AD) that RFC 8619 says "PARAMS ARE absent" =
for
>>>>> the HKDF-based KEY-DERIVATION instances but is silent about how =
one is
>>>>> supposed to know what to pass for salt/info (the IKM we can =
perhaps
>>>>> assume will be obvious).
>>>>>=20
>>>>> In short, should we be seeking to define a distinct key =
combination
>>>>> operation like KRB-FX-CF2 (RFC6113) rather than trying to =
repurpose key
>>>>> derivation?  Some KDFs support this fairly well, but it's not =
clear to
>>>>> me that it is a universal property.  For example, the proof in =
[H2019]
>>>>> seems to be assuming HKDF but this draft does not (as is clearly =
seen
>>>>> from the use of the X9.63 KDF in one of the examples).
>>>>=20
>>>> NIST SP 800-56 Revision 1 offers this high-level interface to the =
KDF:
>>>>=20
>>>>  KDF(Z, OtherInput)
>>>>=20
>>>> - Z: a byte string that represents the shared secret.  This ic =
called IKM in the HKDF terminology.
>>>>=20
>>>> - OtherInput includes:
>>>>=20
>>>>  -- salt - a non-null (secret  or non-secret) byte string.
>>>>=20
>>>>  -- L - a  positive  integer  that  indicates  the  length  (in  =
bits)  of  the  secret  keying  material to be derived.
>>>>=20
>>>>  -- FixedInfo - a bit string of context-specific data that is =
appropriate for the relying key-establishment scheme.
>>>>=20
>>>> I do not think that this very high level of API really solves your =
concern, but it did guide my thinking in writing the document.
>>>=20
>>> It is helpful to see this and understand the origin of what's in the
>>> document.  (Also that the salt is listed as "secret or non-secret" =
here, as
>>> in at least one other place I looked at during my background reading =
I saw
>>> it listed as "not-secret", which would be problematic when we want =
to put a
>>> secret key in it!)
>>=20
>> In thins case, I do not see a need for a secret salt, but the NIST SP =
800-56C API allows for it.
>>=20
>>>> The KDF algorithm identifier has this structure:
>>>>=20
>>>>  AlgorithmIdentifier  ::=3D  SEQUENCE  {
>>>>       algorithm               OBJECT IDENTIFIER,
>>>>       parameters              ANY DEFINED BY algorithm OPTIONAL  }
>>>>=20
>>>> The algorithm part lets us name many different KDFs.  As you point =
out, the examples in Appendix A and Appendix B use HKDF and X9.63 KDF.
>>>>=20
>>>> Recent discussions in the LAMPS WG show a big bias against complex =
parameter strictures.  Instead, people have voiced a strong preference =
for an object identifier that names all of the options.  This leads to =
more object identifier assignments, but clear understanding of all =
options when one is chosen or negotiated.  The one exception is an =
initialization vector, where a fresh value is expected each time the =
algorithm is invoked.
>>>=20
>>> Agreed.
>>>=20
>>>> So, in this document, I have defined a structure of the OtherInput =
portion of the NIST API.  If a particular KDF needs to use a value from =
that structure in a particular way, is can do so.  The document uses =
HKDF terminology.
>>>>=20
>>>> If a KDF requires a salt, then it should be provided as a =
parameter.  I can certainly add that to the document.  I believe that =
KMAC128 and KMAC256 are algorithms that require a salt.
>>>=20
>>> Okay, but I'm not sure we've really gotten onto the same page.
>>=20
>> No, we were not on the same page.  The paragraph below really helps =
me understand your point.
>>=20
>> I few things regarding RFC 2631, RFC 3211, RFC 5912, and RFC 5990 =
just to make sure we are totally on the same page.
>>=20
>> RFC 2631 (Diffie-Hellman Key Agreement Method) and X9.42 use a KDF to =
compute a KEK from a Diffie-Hellman shared secret and an OtherInfo =
structure.  RFC 2631 does not call it a KDF, but X9.42 does so.  The API =
looks a lot like the one for HKDF, except there is no salt.  In fact, =
the X9.42 KDF could work just fine in with this document.
>>=20
>> RFC 3211 (Password-based Encryption for CMS) introduced the =
KeyDerivationAlgorithmIdentifer, but it does not really offer an API.  =
It just says that the algorithm is "used to convert the password into a =
KEK."  It makes PBKDF2, which is specified in RFC 2898, the mandatory to =
implement algorithm, but I do not think it would be straightforward to =
specify the use of HKDF for this purpose.  (I am not sure there is a =
need to do this; PBKDF2 works just fine with modern hash functions.)
>>=20
>> RFC 5912 (New ASN.1 Modules for the Public Key Infrastructure Using =
X.509 (PKIX)) introduced the KEY-DERIVATION class.  It does not nail =
down an API.  It couples the object identifier to a parameter structure =
for the KeyDerivationAlgorithmIdentifer.  RFC5912 uses PBKDF2 as an =
example, so there is no doubt that it was intended to support RFC 321.  =
I do not see anything to prevent the use of the =
KeyDerivationAlgorithmIdentifer with HDDF, X9.63, and many others.
>>=20
>> RFC 5990 (Use of the RSA-KEM Key Transport Algorithm in the =
Cryptographic Message Syntax (CMS)) uses the ALGORITHM class, which is =
very similar to the KEY-DERIVATION class, for two KDFs, whch are defined =
in X9.44:
>>=20
>>   KeyDerivationFunction ::=3D AlgorithmIdentifier {{KDFAlgorithms}}
>>=20
>> Both of these KDFs would seem to fit well with this document.
>=20
> Thanks for laying these out -- I was looking at RFCs 3211 and 5912 =
when
> doing my review, and agree with your conclusions about 2631 and 5990 =
as
> well.
>=20
>>> I think my main question is whether we're comfortable using a KDF
>>> abstraction like the above (KDF(secret, otherInput)) in a fully =
general
>>> sense, and asking for this mix-with-psk to work properly for all =
possible
>>> KDFs.  For example, would you be comfortable using the construction =
in this
>>> document with PBKDF1 as the KDF?
>>=20
>> No.
>>=20
>>> I don't even see where we could slot in
>>> the PSK from this document into PBKDF1 -- the API just doesn't seem =
to be
>>> flexible enough. =20
>>=20
>> Correct.  There is no place to input the CMSORIforPSKOtherInfo to be =
input.
>>=20
>>> PBKDF2 allows a more-than-8-octet salt, but is that going
>>> to provide the kind of mixing that we need?
>>=20
>> Yes, I think it would, but conventions would need to be specified for =
mapping the IKM and info inputs into the password input.  Simple =
concatenation would be okay I suspect.  (Again, I am not sure there is a =
need to do this.)
>=20
> (I'm not sure there's a need, either.)
>=20
>>> I just don't know if all KDFs are going to guarantee the =
contributory
>>> behavior from the otherInput that we need in order for this scheme =
to work.
>>=20
>> So, would text in Section 6 that says an acceptable KDF MUST accept =
IKM, L, and info inputs, and it MAY also accept salt and other inputs.
>=20
> I think that addresses the core of my concern, yes, and would be =
enough to
> resolve the Discuss.  (Technically it doesn't really require that the =
info
> input gets fully mixed in, but if anyone defines a KDF that does that, =
they
> probably deserve what they get.)

I will add a sentence that all of the inputs MUST influence the output =
of the KDF.  I do not want to turn this into a how-to for KDF design...

Russ