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

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Fri, 09 August 2013 08:48 UTC

Return-Path: <kwiereng@cisco.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 B3ADF21F9F50; Fri, 9 Aug 2013 01:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Z+NjzwYwgBji; Fri, 9 Aug 2013 01:48:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D8DB321F9BC1; Fri, 9 Aug 2013 01:48:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2516; q=dns/txt; s=iport; t=1376038117; x=1377247717; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bT/TENNzURX9RzEoLfSc02D3kvIVfKo5MecDBmyaqIs=; b=LzEv/JGRTHi352thw9WOhA3Ele7EsvQQwCqy1DfDbXvA9KSImnwKrajd tABVQIj6vXCDpZACTJZVCj4NF8XJSkJuor9nWqeoyBxoqPyrtYZh740/A gIx3Rq6FeEJs+90DAiVVj08dLRpl6f4hcnJ/nDfmcWwz7bebfseHs87fD g=;
X-Files: signature.asc : 203
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAJ+rBFKtJV2d/2dsb2JhbABbgwaBBb5SgRgWdIIlAQEEeRACAQgiJDIlAgQOBQgGiAK5RY9qMQeDGnQDkBSBLZdvgxiCKg
X-IronPort-AV: E=Sophos; i="4.89,844,1367971200"; d="asc'?scan'208"; a="245379394"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 09 Aug 2013 08:48:34 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r798mYPi022119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 08:48:34 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.38]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 03:48:34 -0500
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: Sam Hartman <hartmans@PAINLESS-SECURITY.COM>
Thread-Topic: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt
Thread-Index: AQHOk4b0Eg4BbEukoUS8XGc9hcW1OpmM5zUA
Date: Fri, 9 Aug 2013 08:48:34 +0000
Message-ID: <7E1636E02F313F4BA69A428B314B77C708CAF367@xmb-aln-x12.cisco.com>
References: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> <tsl61vhwl0b.fsf@mit.edu>
In-Reply-To: <tsl61vhwl0b.fsf@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.100.141]
Content-Type: multipart/signed; boundary="Apple-Mail=_F7A63075-84D5-4C1C-8CCB-E3107EFEEC06"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
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: Fri, 09 Aug 2013 08:48:42 -0000

Russ, Sam,

On Aug 7, 2013, at 5:58 PM, Sam Hartman <hartmans@PAINLESS-SECURITY.COM>; wrote:

>>>>>> "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.

OK, I don't argue that this is what you need at all, so no argument there. The only question I raised is whether one-way is a necessary condition for each and every KDF. I would argue that key stretching not necessarily means one-way .

If you add "in this document" somewhere in the definition I'd be happy, if you don't, no big deal either.

Klaas