Re: [karp] rt-dir review of draft-ietf-karp-crypto-table

Sam Hartman <hartmans-ietf@mit.edu> Thu, 23 May 2013 19:45 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880FC21F89A6 for <karp@ietfa.amsl.com>; Thu, 23 May 2013 12:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 PS2uRPaY4tF5 for <karp@ietfa.amsl.com>; Thu, 23 May 2013 12:44:55 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0CECC21F972C for <karp@ietf.org>; Thu, 23 May 2013 12:08:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C132F2061B; Thu, 23 May 2013 15:05:38 -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 TFl-1oncjgHf; Thu, 23 May 2013 15:05:38 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (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; Thu, 23 May 2013 15:05:38 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 39545440B; Thu, 23 May 2013 15:08:39 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Stephen Kent <kent@bbn.com>
References: <tslwqqswm6e.fsf@mit.edu> <519B99CA.9080307@bbn.com> <m2fvxffqp5.wl%randy@psg.com> <519CE6AE.3000102@bbn.com>
Date: Thu, 23 May 2013 15:08:39 -0400
In-Reply-To: <519CE6AE.3000102@bbn.com> (Stephen Kent's message of "Wed, 22 May 2013 11:39:26 -0400")
Message-ID: <tsl38tdldjc.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: karp@ietf.org
Subject: Re: [karp] rt-dir review of draft-ietf-karp-crypto-table
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: Thu, 23 May 2013 19:45:09 -0000

>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:

    Stephen> Randy, You're right that each BGPSEC router has a private
    Stephen> key. However, the key table is designed to manage key
    Stephen> rollover for keys that are shared on a pairwise basis.  The
    Stephen> private router key does not have that property, so it seems
    Stephen> a bad fit.  I should have been more precise in my reply.

Here are some of the reasons I think the key table is a bad fit for
managing asymmetric key pairs:

* Symmetric key pairs have both a public and private portion.  The
  current key table is designed assuming a single asymmetric key.  It
  doesn't have a concept of a portion of a key row that can be public
  nor does it have a concept of making sure the public key corresponding
  to a private key row is available.

* You often need additional public information such as certificates (or
  in some cases CRLs or cached OCSP responses) to provide to a relying
  party to make an asymmetric key useful.  The key table is not designed
  to manage this information.  I don't know much about BGPSEC, but my
  assumption is that it builds on the RPKI's certificate and key
  management practices.  If so, those practices seem very specialized to
  build into something like the key table.

* The concepts of peers, interfaces, key names and protocol specific
  information seem inappropriate to private keys.