Subject: RE: DH Key Agreement for Pkinit

From: "Paul Leach" <[email-masked]>
Date: Mon, 4 Oct 2004 11:46:26 -0700

I've been told in the past by our resident cryptographers that HMAC is
better, but that the construction in RFC 3766 is good enough. I have
posed that question again, and asked for citations. I will report on
their response.

As to chaniging kcrypto or not, I observe that there is another problem
that has not been solved: the problem of composition of arbitrary
crypto-related mechanisms. I.e., it may not be safe to use the output of
an arbirary function negotiated by PKINIT to generate a symmetric key
with an arbitrary PRF from kcrypto. (It's at least hard to make
statements about arbitrary pairs of such functions.) That's why crypto
suites are invented -- so that the functions used are chosen to work
together properly.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Oct 2004 17:13:40 -0400

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> I've been told in the past by our resident cryptographers
    Paul> that HMAC is better, but that the construction in RFC 3766
    Paul> is good enough. I have posed that question again, and asked
    Paul> for citations. I will report on their response.

OK.  I really think such a response is out of scope for this working
group.  If there are problems with RFC 3766 they probably want to be
brought to the attention of the IESG.

I regret that I didn't find that section of RFC 3766 months ago; it
might have saved significant discussion here.

    Paul> As to chaniging kcrypto or not, I observe that there is
    Paul> another problem that has not been solved: the problem of
    Paul> composition of arbitrary crypto-related mechanisms. I.e., it
    Paul> may not be safe to use the output of an arbirary function
    Paul> negotiated by PKINIT to generate a symmetric key with an
    Paul> arbitrary PRF from kcrypto. (It's at least hard to make
    Paul> statements about arbitrary pairs of such functions.) That's
    Paul> why crypto suites are invented -- so that the functions used
    Paul> are chosen to work together properly.

I'd assume we would use the pkinit-generated function to generate a
random bitstring and then feed that into random-to-key.  At least in
the ephemeral-ephemeral case, I don't see why you would need the PRF.
I believe Larry and others here have actually been assuming that
pkinit would not need the kcrypto PRF at all.  That seems to work for
me.

--Sam