Re: [sidr] preventing SKI collisions

Stephen Kent <kent@bbn.com> Tue, 11 August 2015 19:49 UTC

Return-Path: <kent@bbn.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 33BBF1AD49B for <sidr@ietfa.amsl.com>; Tue, 11 Aug 2015 12:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 MrrmHa1O1Ykc for <sidr@ietfa.amsl.com>; Tue, 11 Aug 2015 12:48:58 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61C71AD2F6 for <sidr@ietf.org>; Tue, 11 Aug 2015 12:48:56 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:50734 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1ZPFXa-000385-U6 for sidr@ietf.org; Tue, 11 Aug 2015 15:48:55 -0400
To: sidr@ietf.org
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>
From: Stephen Kent <kent@bbn.com>
Message-ID: <55CA51A6.1070209@bbn.com>
Date: Tue, 11 Aug 2015 15:48:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com>
Content-Type: multipart/alternative; boundary="------------080301090208030903070603"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/dYgBys9AJS1S6KGMTijXIEX6VK8>
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, 11 Aug 2015 19:49:00 -0000

Sean,

> ...
> Okay so I want to agree.  But, I’m still trying to grok something you sent in an earlier msg (https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI) that I think is related when you said:
>
>    RPs would not have to calculate/validate the SKI value; they would only
>    need to check for collisions within an AS.
No, and yes.

I was chatting with Sandy and noted that a compliant RP does have to 
check that the
SKI is the has of the public key, as per RFC 6487. That RFC says that KI 
values are computed
as SHA-1 hashes of the (relevant) public key (section 4.8.2), and that 
RPs are supposed to
confirm this, as per item #3 in Section 7.2:

           The certificate contains all fields that MUST be present, as
           defined by this specification, *a**nd contains values for**
**          selected fields that are **defined as allowable values by this**
**          specification.

*This requirement is more stringent than what 5280 mandates. 5280 
imposes requirements
on CAs wrt cert generation, but does not require that RPs verify that a 
CA has adhered
to these requirements. This one-sided approach has not worked out well 
in the PKI arena
in general, which is why the RPKI adopted a more symmetric model, i.e., 
specify what
each CA is supposed to do, and then have every RP verify that the CAs 
are doing what they
are supposed to.

So, we can't change the hash alg used to compute KIs in the RPKI, 
without a lot of effort,
something you alluded to later in your message.

Steve