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

[Benjamin Kaduk <[e-mail]>]

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?

Thanks,

Ben