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

Uri Blumenthal <uri@MIT.EDU> Fri, 09 August 2013 12:36 UTC

Return-Path: <uri@mit.edu>
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 859A221F9F74; Fri, 9 Aug 2013 05:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 5TpFnf+5r9Ip; Fri, 9 Aug 2013 05:36:43 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3021F9F31; Fri, 9 Aug 2013 05:36:42 -0700 (PDT)
X-AuditID: 1209190e-b7f988e0000009a7-9f-5204e25a135c
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D3.8A.02471.A52E4025; Fri, 9 Aug 2013 08:36:42 -0400 (EDT)
To: undisclosed-recipients:;
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r79CaeDa014530; Fri, 9 Aug 2013 08:36:40 -0400
Received: from [192.168.1.108] (chostler.hsd1.ma.comcast.net [24.62.227.134]) (authenticated bits=0) (User authenticated as uri@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r79CabcC015343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Aug 2013 08:36:39 -0400
References: <7E1636E02F313F4BA69A428B314B77C708CA7638@xmb-aln-x12.cisco.com> <9D8F4DC5-30E2-4E21-B28C-C44DA6105A5F@vigilsec.com> <tsl61vhwl0b.fsf@mit.edu> <7E1636E02F313F4BA69A428B314B77C708CAF367@xmb-aln-x12.cisco.com> <70181507-3E70-4DED-9E74-2F61CBF63F50@mit.edu>
From: Uri Blumenthal <uri@MIT.EDU>
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPad Mail (10B329)
In-Reply-To: <70181507-3E70-4DED-9E74-2F61CBF63F50@mit.edu>
Message-Id: <BDDEB7F8-B18E-480A-A58B-E3A852152A4E@mit.edu>
Date: Fri, 9 Aug 2013 08:36:38 -0400
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6nrhv1iCXI4PhPUYudf6ewWMz0tJjx ZyKzxdlfTBYfFj5kcWD1mPJ7I6vHkiU/mTxmf2tl9Phy+TNbAEsUl01Kak5mWWqRvl0CV8aW K0uZCt6JVsxd0svawHhZsIuRk0NCwERiw62lzBC2mMSFe+vZuhi5OIQE9jFK3O99CJYQEZCR mDv7MStEYgOjxOLGpSwQzl4miY23ZoBVCQv4Sfybth+qqotJYueLB6wgCTYBJYnm5i1ANgcH s4COxOSFjBDrZCQ2b3/MDmJzClhLTDp9hQWkhFfASuLUu1SQMIuAikTn2TawKcwCK5kkzi0o hrC1JZYtfM0MUS4ucfWgzwRGwVkI82chKZqFULSAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqR rrFebmaJXmpK6SZGUJhzSvLtYPx6UOkQowAHoxIPr8J25iAh1sSy4srcQ4ySHExKorzyd1iC hPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwbp8AlONNSaysSi3Kh0lJc7AoifM+e3o2UEggPbEk NTs1tSC1CCYrw8GhJMEr+xCoUbAoNT21Ii0zpwQhzcTBCTKcB2i4NEgNb3FBYm5xZjpE/hSj McekufM/MXJ8O7bwE6MQS15+XqqUOO+nB0ClAiClGaV5cNNgqeoVozjQc8K8u0CqeIBpDm7e K6BVTECrph8GW1WSiJCSamCsr58y+xTfxd+nP/suWbXh4F1phZieR46bWl/WONv/3mTn+/6l 3kz+ZSkPP9eyxLv/e5Sl0hQZ4VbB/i/o9J6ebsldivLJB58kWzr/i/1i/Eo29vHBlatjmTJz b2w5E3JV83mOSk8QLztj+74Vq/78/xCx6KDNfde2ac/nsy6dGyZ2941nY1iREktxRqKhFnNR cSIA0wIUeDADAAA=
Cc: Sam Hartman <hartmans@PAINLESS-SECURITY.COM>, "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 12:36:50 -0000

I would add that a function that "merely" adds parity to a DES key is a singularly bad example, which is long gone and does not need to be resurrected.

TNX!

Sent from my iPad

On Aug 9, 2013, at 8:28, Uri Blumenthal <uri@MIT.EDU>; wrote:

> IMHO, yes - a KDF must be one-way. Including "key-stretcher" functions.
> 
> TNX!
> 
> Sent from my iPad
> 
> On Aug 9, 2013, at 4:48, "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>; wrote:
> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview