Re: [sidr] preventing SKI collisions

Sandra Murphy <sandy@tislabs.com> Tue, 06 October 2015 12:30 UTC

Return-Path: <sandy@tislabs.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 D1E1D1B4041 for <sidr@ietfa.amsl.com>; Tue, 6 Oct 2015 05:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UFzL70LDODKt for <sidr@ietfa.amsl.com>; Tue, 6 Oct 2015 05:30:22 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5EB1B403F for <sidr@ietf.org>; Tue, 6 Oct 2015 05:30:22 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 9B13028B0041; Tue, 6 Oct 2015 08:30:21 -0400 (EDT)
Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 61B7F1F8035; Tue, 6 Oct 2015 08:30:21 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_3BA0288B-1CAA-4002-9F5F-23BFBB63D4C4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <c6af9ec70934494a2e0dd965c3fe753b@mail.mandelberg.org>
Date: Tue, 06 Oct 2015 08:30:27 -0400
Message-Id: <99B857CD-DF02-4751-880A-E6D1283CF3BE@tislabs.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> <c6af9ec70934494a2e0dd965c3fe753b@mail.mandelberg.org>
To: David Mandelberg <david@mandelberg.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/9vCoSpFkUW49jxe9oCy55kzivSM>
Cc: sidr@ietf.org, Sandra Murphy <sandy@tislabs.com>
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: Tue, 06 Oct 2015 12:30:24 -0000

Speaking as regular ol’ member only.

On Oct 5, 2015, at 4:36 PM, David Mandelberg <david@mandelberg.org> wrote:

> On 2015-09-16 10:38, Sean Turner wrote:
>> 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:
> 
> I was about to argue that BGPsec's requirements for KIs are inherently different than the rest of the RPKI's requirements for KIs, but then I realized that I only thought that way because I'm implementing the relying party side of things and not the BGPsec-enabled router side. So I now agree with you that we can leave #1 and #2 alone for now, but only if we do #4 (which I just made up):
> 
> 4. Add text warning relying parties to detect malicious CAs that cause too many KI collisions, and blacklist those CAs. Similarly, warn routers and/or rpki-rtr caches to detect AS numbers with too many public keys sharing the same SKI, and blacklist those AS numbers.

I’m ok with “warn”, but “blacklist” is a bit strong for me.  If you mean stop using that CA, i.e. remove all objects produced by that CA, then the whole tree under that CA would fall off the planet.  I think that’s a potentially large cone of consequence and I believe it should be undertaken by brains, not code.

I’d prefer a warning in the security considerations section and a recommendation to alert the operator.

—Sandy, speaking as just a regular ol’ member