Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

Tim Bruijnzeels <tim@ripe.net> Thu, 30 October 2014 18: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 526E51A1A65 for <sidr@ietfa.amsl.com>; Thu, 30 Oct 2014 11:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LZ2YBAkNMHLJ for <sidr@ietfa.amsl.com>; Thu, 30 Oct 2014 11:38:45 -0700 (PDT)
Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (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 31CEE1A19EA for <sidr@ietf.org>; Thu, 30 Oct 2014 11:38:45 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1XjucK-0004cp-Pd; Thu, 30 Oct 2014 19:38:42 +0100
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-54.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1XjucK-0001Bg-Lm; Thu, 30 Oct 2014 19:38:40 +0100
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="windows-1252"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <8B92C382-8F04-4BC5-9419-E106119B8FA1@istaff.org>
Date: Thu, 30 Oct 2014 19:38:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <34544385-27D4-4E7D-B465-53AAA2D9623B@ripe.net>
References: <20140702012717.18291.24295.idtracker@ietfa.amsl.com> <415BB336-1A6C-48DD-BD0F-BC9EB0C3506F@ripe.net> <53CFFF3C.2040406@bbn.com> <BB01407F-A226-4531-9FDD-50E1B0A238F0@ripe.net> <53D151F0.80808@bbn.com> <C838412C-D16C-4C88-B022-85484789444A@ripe.net> <53D178A6.7060502@bbn.com> <CFF7CDF2.4AB4B%bje@apnic.net> <65886423-144A-48B5-A0EF-D35D4A4FE890@ripe.net> <CA+z-_EUXA0TWDqHV-9sFbgS2vyXiKE9EKBae6K0eihuhKTsm2A@mail.gmail.com> <53DAA101.8020305@bbn.com> <53E11912.7050904@gmail.com> <53E1486B.1080604@bbn.com> <53E151C7.1090508@gmail.com> <53E24D68.8020705@bbn.com> <75B90A7B-ED14-4716-A12C-2EDB1AA7851D@arin.net> <m2ha1m25iq.wl%randy@psg.com> <CFA4B932-E694-4CD6-B615-341FBD35CF26@arin.net> <m21tsq1j00.wl%randy@psg.com> <06ECFB67-7928-4860-8E1C-C661258E31DD@ripe.net> <8B92C382-8F04-4BC5-9419-E106119B8FA1@istaff.org>
To: John Curran <jcurran@istaff.org>
X-Mailer: Apple Mail (2.1878.6)
X-RIPE-Spam-Level: ---
X-RIPE-Spam-Report: Spam Total Points: -3.5 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.6 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: 784d7acfe6559f2a0b602ec6519a07191dc18d289657afccf367d7679423edf2
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/kakb5CfiF_qylDp0AI14uDZWh_I
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt
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: <http://www.ietf.org/mail-archive/web/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, 30 Oct 2014 18:38:47 -0000

Hi John, all,

Hoping to clarify my reasoning why I think this is validation approach provides a significant quick win..


On 29 Oct 2014, at 00:17, John Curran <jcurran@istaff.org> wrote:

> On Aug 11, 2014, at 11:58 AM, Tim Bruijnzeels <tim@ripe.net> wrote:
>> ...
>> The *one* thing I (and I believe we..) challenge is whether the an overclaimed resource should invalidate a complete certificate, instead of invalidating just the resources at hand, but allowing the remainder.
>> ...
>> The following two we may be able to mitigate technically, because we are dealing with co-operating parties:
>> @1 There is a mis-timing in certificate shrinking in a transfer between co-operating parties.
>> @2 There is a mis-timing in the parent publishing a cert with extended resource, and issuing it to the child, and the child using those resources in turn.
>> 
>> But this is the one that has me scared. It is not the issuing CA being sloppy, it’s a problem between them and *their* parent:
>> @1 The *grand*-parent shrinks the *parent* certificate without the parent knowing about this, and some of these resources appear on the, now overclaiming, child certificate. The grand-parent and parent are not involved in an active transfer process. They may not agree that the resource in question should be removed, or the grand-parent may have shrunk these resources in error.
>> 
>> By rejecting the overclaiming child certificate completely I think we are being too harsh, or pedantic even. We know better, so we are just not going to trust this one. But.. there is a very real possibility that we actually *do* know better than the issuing CA at this point. So, what exactly is the problem with accepting the remaining resources? i.e. the intersection between the parent certificate’s resources and this certificate. We know the context, this evaluation is very easy and well-defined. If the CA really intended that the remaining resources should not be tied to the certificate, they would have revoked. If the grand-parent really intended that those resources should not be certified anymore, they would have removed them as well.
> 
> I'm certain there is a simple answer for this question, but it alludes me
> at the present time…

I would very much like to learn the answer to that question though, taken from above:
>> So, what exactly is the problem with accepting the remaining resources?


I believe we are rejecting ROAs or router certificates under strict rules for reasons that concern other objects. I just do not see a scenario where an RP could be led to accept a ROA or router certificate that *could* not be valid if strict rules are followed. The fix is higher in the chain. By claiming fewer resources, not more. And the exact same object would be considered valid.

If someone can come up with a scenario where a truly over claiming ROA or router certificate is considered valid under reconsidered rules, then I agree that it’s not option.

As it stands in my understanding though, this is an easy quick fix to limit the impact of problem of over claiming certificates to just *those* objects that refer to the resources.

So even if it then doesn’t solve those other issues, I believe we will have made a very significant improvement.

Tim