Subject: RE: Concern: Does kcrypto imply that PRF is really a PRF

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 27 Sep 2004 13:12:49 -0700

Jeffrey Hutzelman wrote:

> Please allow me to be clear.  This document is OUT OF OUR HANDS. 

Which way has less work? Recalling this draft now or coming up with the
next version of it?

-- Larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Monday, September 27, 2004 1:05 PM
To: Nicolas Williams; Paul Leach
Cc: Ken Raeburn; Liqiang(Larry) Zhu; [email-masked]
Subject: Re: Concern: Does kcrypto imply that PRF is really a PRF

On Monday, September 27, 2004 14:06:47 -0500 Nicolas Williams
<[email-masked]> wrote:

> a) Is the kcrypto PRF construction cryptographically strong?  I don't
>    know, but I don't see why it wouldn't be strong enough in the
context
>    of PKINIT, where some of the bits of the input string are secret,
not
>    just the key's bits.
>
> b) Can we add those magic words to kcrypto?  No, I don't think so, not
>    without some innormative reference to relevant definition and
>    analysis of such a construction.  If such references exist then
>    adding them to kcrypto in 48hrs author's review should be feasible
>    (since adding the references does not change the spec).
>
> c) Should we change the kcrypto PRF construction so it outputs more
>    bits?  I don't see why, short of finding that the kcrypto PRF
>    construction is not cryptographically strong (for strong ciphers
and
>    hashes, of course), since truncation and a PRF+ are sufficient to
>    deal with impedance mismatches.

Allow me to clarify something here.

The kcrypto document does two things relevant to this discussion:

(A) It defines the parameters that must be specified for every enctype.
    One of these parameters it the definition of a PRF.  The document
    says the PRF MUST have these properties:

      This pseudo-random function should generate an octet string of
      some size that independent of the octet string input.  The PRF
      output string should be suitable for use in key generation, even
      if the octet string input is public.  It should not reveal the
      input key, even if the output is made public.

    That's three properties:
    - The size of output is not dependent on the input.
    - The output quality must be good enough for keying material, even
      if the input string is public or well-known.  Note that it does
      not say that the output must be a key of any particular type,
      only that it should be "suitable for use in key generation".
    - The output must not reveal the input key.

    We apparently erred here in not saying MUST, but then, this document
    is for writers of future enctypes, not implementors, and writers of
    future standard enctypes have the full powers of IETF concensus.

(B) It describes how to construct enctypes based on a simplified
profile.
    Part of this description includes the definition of the PRF for all
    enctypes that use the simplified profile, including AES and 3DES.
    This definition does not apply to the single-DES enctypes.

As near as I can tell, this thread started out with a question as to
whether (A) required that the PRF be cryptographically strong, thereby
allowing us to depend upon that property in the construction of
protocols like PKINIT.  However, it seems to have devolved rather
quickly into a discussion of the particular PRF defined by (B), and
whether it is suitable for a variety of uses.

It's not unreasonable to discuss whether the PRF defined by (B) is
cryptographically strong.  After all, if it is not, then we cannot add
that requirement to (A) without fixing it.  From the discussion so far,
it appears to me that the group does agree that the PRF defined by (B)
is indeed cryptographically strong.  If anyone disagrees with this
narrow conclusion, please say so now.

It is also not unreasonable to discuss whether the PRF defined for the
single-DES enctypes is cryptographically strong.  Again, if it is not,
then we cannot add that requirement to (A) without fixing it.  I have
seen _no_ discussion on this topic, so I will ask folks to examine this
again now. 
If anyone believes that the PRF defined for DES-CBC-{CRC,MD4,MD5} is
_not_ cryptographically strong, please say so now.

OK.  So now we have a requirement we'd like to specify, and hopefully
some PRF's which meet the requirement, and a document that is bubbling
its way to the top of the RFC-Editor's queue.  Where we go from here
depends on whether we believe the PRF's already in the document meet the
requirement, or if we have to replace one or both of them.

(1) We can, of course, do nothing at all.

(2) If the PRF's defined in the document meet the requirement, then I
    believe we can add a sentence spelling out the requirement during
    final editing.  I find this acceptable only because it is clear to
    me from discussion, intended uses, and the existing definitions
    that it has always been the intent to have this requirement.  Even
    so, this option is subject to AD approval.

(3) If the PRF's defined in the document do not meet the requirement,
    then we will have to change them in order to add the text which
    states the requirement.  This will require recalling the document
    from the RFC-Editor, obtaining a WG concensus on the changes, and
    re-submitting it.  Again, it is possible the AD will not permit
    us to do this at this late date.

Please allow me to be clear.  This document is OUT OF OUR HANDS.
Getting it back is a significant step, which we should undertake only if
it is absolutely necessary.  So, please ask yourselves this - is it
really necessary to change the definitions of these PRF's, or is it
merely something that would be nice?

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Sep 2004 15:11:42 -0500

> Which way has less work? Recalling this draft now or coming up with the

Larry, so far you have not convinced anyone (that I've seen) that the
document needs updating.  Before asking that question we ought to know
what we'd be changing in the spec.  We don't.

Nico
--