Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-mix-with-psk-06: (with DISCUSS and COMMENT)

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Aug 22, 2019 at 10:00 PM Benjamin Kaduk <[e-mail]> wrote:

> Hi Russ,
>
> On Fri, Aug 16, 2019 at 02:09:03PM -0400, Russ Housley wrote:
> > Ben:
> >
> > Thanks for doing all of the reading necessary to raise this question.
> >
> > I want to respond to the DISCUSS in this note.  I'll tackle the
> non-blocking comments is a separate message.
>
> Sorry that I did not more effectively make use of the extra lead time you
> gave me.
>
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > >
> > > 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).
> > >
> > > 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).
> >
> > NIST SP 800-56 Revision 1 offers this high-level interface to the KDF:
> >
> >    KDF(Z, OtherInput)
> >
> >   - Z: a byte string that represents the shared secret.  This ic called
> IKM in the HKDF terminology.
> >
> >   - OtherInput includes:
> >
> >    -- salt - a non-null (secret  or non-secret) byte string.
> >
> >    -- L - a  positive  integer  that  indicates  the  length  (in
> bits)  of  the  secret  keying  material to be derived.
> >
> >    -- FixedInfo - a bit string of context-specific data that is
> appropriate for the relying key-establishment scheme.
> >
> > 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.
>
> 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!)
>
> > The KDF algorithm identifier has this structure:
> >
> >    AlgorithmIdentifier  ::=  SEQUENCE  {
> >         algorithm               OBJECT IDENTIFIER,
> >         parameters              ANY DEFINED BY algorithm OPTIONAL  }
> >
> > 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.
> >
> > 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.
>
> Agreed.
>
> > 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.
> >
> > 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.
>
> Okay, but I'm not sure we've really gotten onto the same page.
>
> 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?  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.  PBKDF2 allows a more-than-8-octet salt, but is that going
> to provide the kind of mixing that we need?
>
> 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.
>

The ability to change algorithm is a good thing. But proliferation of
mechanisms is not. I really dislike the fact that we have three dozen SASL
mechanisms that do the same thing.

The ability to use a KDF keyed by a different hash function seems like it
is useful agility.

I really cannot imagine a situation in which we discovered an urgent need
to move away from HKDF that didn't require us to think really hard about
the replacement algorithm as well.