Re: [secdir] draft-ietf-karp-crypto-key-table-07
Sam Hartman <hartmans@painless-security.com> Fri, 19 April 2013 14:22 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 6A07C21F919D; Fri, 19 Apr 2013 07:22:32 -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=[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 sAJMHn0Nee3q; Fri, 19 Apr 2013 07:22:31 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D0B2B21F90AC; Fri, 19 Apr 2013 07:22:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id DF37D202AC; Fri, 19 Apr 2013 10:22:25 -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 8Su-7LzSh6lh; Fri, 19 Apr 2013 10:22:25 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Fri, 19 Apr 2013 10:22:25 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6874F4499; Fri, 19 Apr 2013 10:22:26 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
References: <7E1636E02F313F4BA69A428B314B77C708B0EDEF@xmb-aln-x12.cisco.com>
Date: Fri, 19 Apr 2013 10:22:26 -0400
In-Reply-To: <7E1636E02F313F4BA69A428B314B77C708B0EDEF@xmb-aln-x12.cisco.com> (Klaas Wierenga's message of "Fri, 19 Apr 2013 14:05:22 +0000")
Message-ID: <tslehe6zjkt.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (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] draft-ietf-karp-crypto-key-table-07
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, 19 Apr 2013 14:22:32 -0000
>>>>> "Klaas" == Klaas Wierenga (kwiereng) <kwiereng@cisco.com> writes: Klaas> * 1 Intro Klaas> What is conceptual about it? Isn't this supposed to be a Klaas> specification of the format for a real database? No. It's exactly to avoid getting into a discussion of normalization and most of the comments you discuss in your comments on section two that we want this to be conceptual. We don't want to go there because there is no interoperability advantage to specifying things at that level of detail . Klaas> * 2 Conceptual Database Structure Klaas> introductory paragraph: it is hard to grasp why or why not Klaas> you want to have the same key appear twice without Klaas> understanding what the format of the database will look Klaas> like. So I think you should move that part of the first Klaas> paragraph to below the column definition. Klaas> Peers: hmm, so now you have a multivalued column of arbitrary Klaas> length? What is the separator? And do you expect Klaas> normalisation into separate tables to happen? Since we're a conceptual database we don't need to answer any of that:-) To describe the key selection algorithm we need to say it's a set. To have interoperability within protocols we need each protocol to define the format of a member of the set, but *not* how to represent a set as a whole. If we defined a netconf schema we might well need to define how to add and remove members from this set. The natural way to do this will be vendor specific; the way I'd define a IOS-style CLI would be very different than what I'd do for something grabbing configuration from an SQL database. Klaas> Protocol: So here you want only a single security protocol, Klaas> resulting in rows with the same key but different Klaas> protocols. Resulting in a more complex lookup but no Klaas> normalisation into separate tables necessary, I'd say best to Klaas> choose one solution and stick to it. In general, the protocol value is very likely to influence what keys are valid. We also want to strongly discourage the same key being used between protocols.
- [secdir] draft-ietf-karp-crypto-key-table-07 Klaas Wierenga (kwiereng)
- Re: [secdir] draft-ietf-karp-crypto-key-table-07 Sam Hartman
- Re: [secdir] draft-ietf-karp-crypto-key-table-07 Klaas Wierenga (kwiereng)