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 Fri, Aug 23, 2019 at 12:58 PM Benjamin Kaduk <[e-mail]> wrote:

> Hi Phill,
>
> On Thu, Aug 22, 2019 at 11:07:12PM -0400, Phillip Hallam-Baker wrote:
> > On Thu, Aug 22, 2019 at 10:00 PM Benjamin Kaduk <[e-mail]> wrote:
> >
> > > Hi Russ,
> > >
> > > 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.
>
> While I agree with you, I'm not entirely sure what you see as the
> consequences for this document.  Are you proposing that we just restrict
> its usage to HKDF-based KDFs for now?
>

Given your comments, I think that works better than trying to abstract out
an API and then map other KDFs onto it.

Since we build KDFs on a hash function, the API pretty much defines the KDF
structure. There are design choices in a KDF but I really hope they are not
security concerns because that would suggest HMAC is broken or we don't
know how to use a MAC.

I see the choice of KDF as being a part of the CMS specification that just
happens to be available for re-use in other specifications. While there may
be good reason to add to the number of KDFs supported, I don't think we
need to anticipate or plan for that.