Subject: Re: [kitten] AD review of draft-ietf-kitten-pkinit-alg-agility-03

From: Greg Hudson <[email-masked]>
Date: Sun, 3 Feb 2019 11:52:54 -0500

On Wed, Jan 30, 2019 at 04:45:55PM -0600, Benjamin Kaduk wrote:
>    To name the input parameters, an abbreviated version of the ASN.1
>    version of the KDF from [SP80056A] is described below, use [SP80056A]
>    for the full reference.
>
> [SP80056A] seems to call this a "KDM" and not a "KDF"; we probably want to
> call out the terminology mismatch and perhaps also the section number
> (5.8?).  Also, the actual algorithm seems to be coming from Section 4 of
> SP800-56C, not SP800-56A, if we want to be accurate about our reference.

The draft reference was accurate for the original SP800-56A, but there
has been some drift in revisions to the NIST document.  Fortunately,
none of the changes invalidate our formulation of the KDF.

The revisions do seem to have introduced the term KDM as you say,
perhaps to distinguish key derivation beginning with a DH shared secret
from key derivation beginning with an existing key (SP800-108).
However, the terms "key-derivation function" and "KDF" still appear in
SP800-56C several times, such as at the top of section 4.  So I didn't
see a need to call out the terminology difference.

I updated the references to account for the SP800-56 revisions, and
changed the terminology in the abbreviated description of the KDF to
match the revised NIST recommendations.

>    o  The maximum hash input length is 2^64 in bits.
>
> I'm confused where this parameter comes from.  On the one hand, that's an
> absurdly huge value; on the other hand, why do we need to give a limit at
> all?

SP800-56C section 4.1 has max_H_inputBits as an implementation-dependent
parameter.  (The original SP800-56A had something similar.)  It is only
used for an error check.  Since SHA-1 and SHA-2 hash functions do not
limit the hash input size, we just need to set a value large enough not
to trigger the error check.

>    If the supportedKDFs field is not present in the request, the kdf
>    field in the reply MUST be absent.
>
> Somehwere in here we should probably say that if the supportedKDFs field is
> absent, implementations continue to use the RFC 4556 KDF (if they continue
> at all).

We might also give the KDC the option of rejecting the request, if it
does not expect requests from old clients.  (I didn't make that change
in my revision as that wouldn't have been editorial, but I did clarify
that the RFC 4556 KDF must be used.)

I believe I addressed all of your other comments in the -04 update.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 3 Feb 2019 15:32:21 -0600

> I believe I addressed all of your other comments in the -04 update.

Thanks for all these updates (and explanation of non-updates); I've gone
ahead and requested the IETF Last Call.

-Ben