Re: [sidr] preventing SKI collisions

Russ Housley <housley@vigilsec.com> Wed, 16 September 2015 14:42 UTC

Return-Path: <housley@vigilsec.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 16E591B3F93 for <sidr@ietfa.amsl.com>; Wed, 16 Sep 2015 07:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 GPCX15bYxgNb for <sidr@ietfa.amsl.com>; Wed, 16 Sep 2015 07:42:39 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id E46911B3F90 for <sidr@ietf.org>; Wed, 16 Sep 2015 07:42:38 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 862889A404C; Wed, 16 Sep 2015 10:42:28 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 4TeHrOlg3RNf; Wed, 16 Sep 2015 10:41:31 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 26F8A9A40CE; Wed, 16 Sep 2015 10:42:28 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="windows-1252"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <D008D28C-FC51-4AB7-9F73-C2435408AED6@ieca.com>
Date: Wed, 16 Sep 2015 10:42:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <66D07138-EEC8-4FCA-A280-0609F98CF644@vigilsec.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> <D008D28C-FC51-4AB7-9F73-C2435408AED6@ieca.com>
To: Sean Turner <turners@ieca.com>, Richard Hansen <rhansen@bbn.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/hs6t8IlDB63RJFlBh1UJvTTf3TE>
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:42:40 -0000

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

I support this way forward.

Russ