Re: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt

Sam Hartman <hartmans@painless-security.com> Wed, 07 August 2013 15:58 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3099B21E8143; Wed, 7 Aug 2013 08:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfGSeW8aB+tt; Wed, 7 Aug 2013 08:58:37 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3597011E813F; Wed, 7 Aug 2013 08:58:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3F68D2022C; Wed, 7 Aug 2013 11:57:39 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpToLqEgCaCg; Wed, 7 Aug 2013 11:57:37 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (gain1-180.nortex.net [63.160.158.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 7 Aug 2013 11:57:37 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8CAF080E01; Wed, 7 Aug 2013 11:58:28 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: Russ Housley <housley@vigilsec.com>
References: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com>
Date: Wed, 07 Aug 2013 11:58:28 -0400
In-Reply-To: <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> (Russ Housley's message of "Wed, 7 Aug 2013 10:19:28 -0400")
Message-ID: <tsl61vhwl0b.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-karp-crypto-key-table.all@tools.ietf.org" <draft-ietf-karp-crypto-key-table.all@tools.ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2013 15:58:43 -0000

>>>>> "Russ" == Russ Housley <housley@vigilsec.com>; writes:

    Russ> Klaas: The property you describe depends on the inputs to the
    Russ> KDF, not just the definition of the function.

    Russ> Notice that an IANA registry is defined, and each entry should
    Russ> point to a definition of the function.

So, there are a couple of things.
There are functions that take a random bit string and convert them into
a key.  For example if you have 56 random bits and want a 64-bit
correct-parity DES key.

I don't have  a good name for such a function but it's not a KDF.

There are functions that take the output of key agreement (DH, ECDH,
etc) and convernt into a good symmetric key.  I've heard those described
as key expansion functions or KDFs.

There are functions that take one symmetric key and turn it into another
symmetric key so that you can construct a key hierarchy.  I've also seen
these described as KDFs.  It's probable that any function that's really
good at taking key agreement output as input and producing a strong key
will also be good enough  for establishing a key hierarchy.

I'm not aware of definitive definitions in this space, and I'm fairly
sure the text we added in 08 is what we mean for this document.