IETF Logo Mail Archive

Re: [sidr] preventing SKI collisions

Tim Bruijnzeels <tim@ripe.net> Fri, 07 August 2015 08:38 UTC

Return-Path: <tim@ripe.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 A908E1ABD3F for <sidr@ietfa.amsl.com>; Fri, 7 Aug 2015 01:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-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 iVA9EprbzIck for <sidr@ietfa.amsl.com>; Fri, 7 Aug 2015 01:38:14 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 C4B691ABC10 for <sidr@ietf.org>; Fri, 7 Aug 2015 01:38:14 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1ZNdAI-000CKP-QC; Fri, 07 Aug 2015 10:38:11 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-64.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1ZNdAI-00063D-IE; Fri, 07 Aug 2015 10:38:10 +0200
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com>
Date: Fri, 07 Aug 2015 09:38:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net>
References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com>
To: Sean Turner <turners@ieca.com>
X-Mailer: Apple Mail (2.2102)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ---
X-RIPE-Spam-Report: Spam Total Points: -3.0 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071915185c8fa2d06f21c0e92dcb62340537
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/wOPdCUL_6Y9NYuoT61ByKnnGjm4>
Cc: sidr wg list <sidr@ietf.org>, "rhansen@bbn.com" <rhansen@bbn.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: Fri, 07 Aug 2015 08:38:16 -0000

Hi Sean,

Specifically on this point:

> On Aug 7, 2015, at 12:52 AM, Sean Turner <turners@ieca.com> wrote:
> 
> I’m all for switching to using a better hash algorithm to avoid collisions, but why can’t we just do it anytime we want?  The SKI/AKI fields are only ever generated by a CA so the RPs don’t need to know the algorithm used.

This change would require certificates to be re-issued (or possibly keys to be rolled) all the way down from Trust Anchors. When the parent CA re-issues a certificate for the child CA with a new style SKI, then the child will have to re-issue its products with a new AKI.

This is not impossible, but not trivial either. Especially if a delegated model is used.

I am still not sure that avoiding collisions is that important in this case. Proof of possession of the keys is verified through other means.

A specific example: we have changed our validation algorithm to find the most current *valid* MFT for a CA certificate by matching the SKI of the CA certificate with the AKI of the MFT EE certificate. But we do check that it's validly signed. So an accidental collision, or even a maliciously crafted MFT (with a colliding AKI on its EE cert), should not matter.

But if I am missing a stronger reason I would like to know.

I agree that if we need to change this it's better to address this sooner rather than later.

Tim

v2.23.0 | Report a Bug | By Email