Re: [sidr] preventing SKI collisions

Sean Turner <turners@ieca.com> Wed, 16 September 2015 14:38 UTC

Return-Path: <turners@ieca.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0611B3F4C for <sidr@ietfa.amsl.com>; Wed, 16 Sep 2015 07:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YyM-xABkbJG for <sidr@ietfa.amsl.com>; Wed, 16 Sep 2015 07:38:44 -0700 (PDT)
Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.55.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9351B3F47 for <sidr@ietf.org>; Wed, 16 Sep 2015 07:38:44 -0700 (PDT)
Received: by gateway20.websitewelcome.com (Postfix, from userid 500) id E4F61E1EFD74; Wed, 16 Sep 2015 09:38:43 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway20.websitewelcome.com (Postfix) with ESMTP id D131CE1EFD42 for <sidr@ietf.org>; Wed, 16 Sep 2015 09:38:43 -0500 (CDT)
Received: from [75.144.26.38] (port=53477 helo=[10.0.0.131]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from <turners@ieca.com>) id 1ZcDr9-000764-44; Wed, 16 Sep 2015 09:38:43 -0500
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Turner <turners@ieca.com>
In-Reply-To: <55CA4901.4010007@bbn.com>
Date: Wed, 16 Sep 2015 07:38:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D008D28C-FC51-4AB7-9F73-C2435408AED6@ieca.com>
References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> <m2wpx7pes6.wl%randy@psg.com> <55C4D7C8.4000401@bbn.com> <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> <55CA4901.4010007@bbn.com>
To: Richard Hansen <rhansen@bbn.com>
X-Mailer: Apple Mail (2.1878.6)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 75.144.26.38
X-Exim-ID: 1ZcDr9-000764-44
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([10.0.0.131]) [75.144.26.38]:53477
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 3
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/L0TE1KH8Tfv1UNt3UTcG7trdMww>
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] preventing SKI collisions
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2015 14:38:46 -0000

On Aug 11, 2015, at 12:12, Richard Hansen <rhansen@bbn.com> wrote:

> Unfortunately no, with the disclaimer that I haven't really thought
> about it in depth.  Because of the challenge of accomplishing topic #3,
> I would like start with the much simpler topic #1.  Note that I'm not
> opposed to tackling #3, but the amount of work involved means that I'd
> like to get topic #1, and possibly topic #2, out of the way first.
> 

Okay so I think we’re in agreement here that we don’t work on #3 now, but I’m also thinking that we should leave #1 and #2 alone for now.   If we think a SHA-1 hash for the RPKI’s KIs are good enough now, then it sounds like it's also good enough for BGPsec.  It seems really odd that we do something different in BGPsec than what is done in the rest of the RPKI.  So, I’m proposing that:

1. We make no change to the SKI generation mechanism.

2. To make sure folks don’t continue to go down this rathole I think we should add the following to the security considerations, which is copied from RFC 7093:

  While hash algorithms provide preimage resistance, second-preimage
  resistance, and collision resistance, none of these properties are
  needed for key identifiers.

3. We tackle the KI algorithm change we/if we re-open the RPKI PKI profile.

spt