Re: [secdir] draft-ietf-karp-crypto-key-table-07

"Klaas Wierenga (kwiereng)" <> Fri, 19 April 2013 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1644821F8F2E; Fri, 19 Apr 2013 07:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZfKFuop45iKm; Fri, 19 Apr 2013 07:48:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1808A21F8F1C; Fri, 19 Apr 2013 07:48:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2819; q=dns/txt; s=iport; t=1366382888; x=1367592488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mEJxhE2zToRj0/qDMCVftV+50h5MdemV/rxkvMjEsdg=; b=Ivti4KFqdLuTYPwiqW+ZzM9lpwIAMnLcO610IWffmDaTcvW4g7oPKb4X QiLv284ZJ1QNDRFH0D9q99I0eNVkYr5O+0qVY5vNj4VxlTO1jUFiKd6c6 FoHzwSXpKiXi9ygye5DPpwoPCPJFKgvqfzjFG1UGfKJ/L7Awj8F+jCb/J U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,509,1363132800"; d="scan'208";a="200720172"
Received: from ([]) by with ESMTP; 19 Apr 2013 14:48:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r3JEm74W001414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 14:48:07 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 09:48:07 -0500
From: "Klaas Wierenga (kwiereng)" <>
To: Sam Hartman <hartmans@PAINLESS-SECURITY.COM>
Thread-Topic: draft-ietf-karp-crypto-key-table-07
Thread-Index: AQHOPQbuce+OHU+sDECZBdq2jRPubJjdmJ6agABa8oA=
Date: Fri, 19 Apr 2013 14:48:07 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, The IESG <>, "" <>
Subject: Re: [secdir] draft-ietf-karp-crypto-key-table-07
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Apr 2013 14:48:09 -0000

On Apr 19, 2013, at 4:22 PM, Sam Hartman <hartmans@PAINLESS-SECURITY.COM>; wrote:

>>>>>> "Klaas" == Klaas Wierenga (kwiereng) <>; 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:-)

hmm ok, I see your point

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

Yes, I understand that argument, but….. just like with peers you can argue that you don't have to answer any questions about whether you want extra records or multiple protocols per key in 1 record. It just suffices to say that you discourage the use of the same key for multiple protocols. Anyway, I don't feel strongly about this, it just felt inconsistent.