[karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08

"Black, David" <david.black@emc.com> Fri, 09 August 2013 15:19 UTC

Return-Path: <david.black@emc.com>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9A0BC11E8196; Fri, 9 Aug 2013 08:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.583
X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rxH3MI7Ew7wF; Fri, 9 Aug 2013 08:19:28 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com []) by ietfa.amsl.com (Postfix) with ESMTP id 86E9021F9EFC; Fri, 9 Aug 2013 08:11:18 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r79ElVGn030222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2013 10:47:31 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com []) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 9 Aug 2013 10:47:07 -0400
Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r79El6Ae021361; Fri, 9 Aug 2013 10:47:06 -0400
Received: from mx15a.corp.emc.com ([]) by mxhub24.corp.emc.com ([]) with mapi; Fri, 9 Aug 2013 10:47:05 -0400
From: "Black, David" <david.black@emc.com>
To: "housley@vigilsec.com" <housley@vigilsec.com>, "tim.polk@nist.gov" <tim.polk@nist.gov>, "Sam Hartman (hartmans@painless-security.com)" <hartmans@painless-security.com>, "Dacheng Zhang (zhangdacheng@huawei.com)" <zhangdacheng@huawei.com>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>
Date: Fri, 9 Aug 2013 10:47:05 -0400
Thread-Topic: Gen-ART review of draft-ietf-karp-crypto-key-table-08
Thread-Index: Ac6VD0rmlAaf+56PTd+LLDqqvEOcAQ==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Black, David" <david.black@emc.com>, "karp@ietf.org" <karp@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2013 15:19:37 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>gt;.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-karp-crypto-key-table-08
Reviewer: David L. Black
Review Date: August 9, 2013
IETF LC End Date: April 29, 2013
IETF Telechat Date: August 15, 2013

Summary:  This draft is on the right track, but has open issues
described in the review.

This draft describes a conceptual key database for use by protocols.
It's definitely useful and valuable work, as key management is often
an afterthought in protocol design, even when security functionality
is actively worked on in the design process.  The draft text is in
good shape and reads cleanly.

The draft authors have addressed most of the issues and concerns from
the GenART review of the -07 version of this draft, but three issues
remain.  I am particularly concerned with the first issue about whether
FCFS is appropriate for these security-related registries, and believe
that topic deserves IESG discussion.  The three issues are ([9], [A] and
[C] are the issue identifiers used on the original Gen-ART review of the
-07 version of this draft):

Major issue:

[9] I suggest Expert Review for the new IANA registries, not just 
First Come First Served, so that someone with a security "clue" can
check that the proposed registrations are reasonable.

Minor issues:

[A] Overall - I would like to see a paragraph added on how this database
conceptually relates to the IPsec Peer Authorization Database (PAD) -
see RFC 4301, section 4.4.3.

[C] (Section 3) Where does key selection occur?  I would suggest that
the database return all possible keys and let the protocol figure out
what to use.  This is particularly important for inbound traffic for
obvious reasons.

Nits/editorial comments:

First paragraph in 8.1.2 should be at end of 8.1.1.

idnits 2.12.17 found two nits - the latter one (2119 reference/boilerplate)
needs attention:

  ** There are 2 instances of too long lines in the document, the longest one
     being 6 characters in excess of 72.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119

     RFC 2119 keyword, line 194: '...tion of key material.  The KDF MAY use...'
     RFC 2119 keyword, line 196: '... or received but MUST NOT depend on ot...'

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754