Re: [sidr] preventing SKI collisions

Rob Austein <sra@hactrn.net> Thu, 08 October 2015 20:18 UTC

Return-Path: <sra@hactrn.net>
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 14BF01ACD2B for <sidr@ietfa.amsl.com>; Thu, 8 Oct 2015 13:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 LCbkQyoI7JIf for <sidr@ietfa.amsl.com>; Thu, 8 Oct 2015 13:18:42 -0700 (PDT)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22BD1ACD2A for <sidr@ietf.org>; Thu, 8 Oct 2015 13:18:42 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 2B3553982A for <sidr@ietf.org>; Thu, 8 Oct 2015 20:18:42 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id A032B1C68DAD for <sidr@ietf.org>; Thu, 8 Oct 2015 16:17:51 -0400 (EDT)
Date: Thu, 08 Oct 2015 16:17:51 -0400
From: Rob Austein <sra@hactrn.net>
To: sidr@ietf.org
In-Reply-To: <C6707353-65E9-49B2-8D50-F317127EA7F8@sn3rd.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> <99B857CD-DF02-4751-880A-E6D1283CF3BE@tislabs.com> <C6707353-65E9-49B2-8D50-F317127EA7F8@sn3rd.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20151008201751.A032B1C68DAD@minas-ithil.hactrn.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/wGki_B-5SwIl8y6VMonv2j9mSAU>
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: Thu, 08 Oct 2015 20:18:44 -0000

At Wed, 7 Oct 2015 09:22:40 -0400, Sean Turner wrote:
> 
> On Oct 06, 2015, at 08:30, Sandra Murphy <sandy@tislabs.com> wrote:
>> On Oct 5, 2015, at 4:36 PM, David Mandelberg <david@mandelberg.org> wrote:
>>>
>>> 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.
> 
> Yep let?s just put a warning in the security considerations and
> alert the operator.

Agreed.  "Blacklist" sounds too much like mandatory policy.
My RP, who are you to decide how much of its CPU time I should waste?