Re: [Sidrops] 6486bis: referenced object validation

Ties de Kock <tdekock@ripe.net> Fri, 04 December 2020 13:13 UTC

Return-Path: <tdekock@ripe.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1CA3A07F0; Fri, 4 Dec 2020 05:13:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
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 9R4kZaEBSmvM; Fri, 4 Dec 2020 05:13:43 -0800 (PST)
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 ACE633A07DB; Fri, 4 Dec 2020 05:13:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version: Content-Type; bh=4rcmWWdDJLzLdOuJ8w9tu2GLXirPGxZEBGaxOTiiPWo=; b=UqEaxiECl1/z 4Yn/D6lIeNHvVe4xX+qJWNq0i/tLMvdUkhTbtsvP2P9p6OHBb8zqqh+8mbYNHKZyjFQcNaiy0T0Z/ BTQNMLpY9klApUNroI6BkUoPjOVyWN88ORhBD9ST3OL/Vj+EpywnMTZlzRzczkpRWnANGnIniF0CC 51+KbAU370bgw9oj0+PmdOcLCJrgHrlkAohwZfmyJ4idpt2j5cRRl1bNhUGDFS3L4c6iO/58y3qNE fXA702DZmivnokSJCYukSpX6XEQdlhyaw3VR+EzWW92s3E+chy4Lv7oeeUEq+mlJpsLrofbs1ihgF c2jl9YdoF1DGhQg/uG7V3Q==;
Received: from bufobufo.ripe.net ([193.0.23.13]:54084) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <tdekock@ripe.net>) id 1klAu6-0009tP-8t; Fri, 04 Dec 2020 14:13:42 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::99d]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <tdekock@ripe.net>) id 1klAu6-0003eb-5y; Fri, 04 Dec 2020 14:13:42 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <X8oarQL4yLjPuRxP@bench.sobornost.net>
Date: Fri, 4 Dec 2020 14:13:41 +0100
Cc: sidrops@ietf.org, Martin Hoffmann <martin@opennetlabs.com>, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F820FD40-DC95-411E-8C69-F6877CDA4196@ripe.net>
References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <X8oSBlR1pDhX83nH@bench.sobornost.net> <EF03D4E0-83EE-4C70-8E81-002DC8C38B95@ripe.net> <X8oUr+zsCbHk0Q3a@bench.sobornost.net> <78C30B6C-820E-49E9-BE88-6137A26F38E2@ripe.net> <X8oarQL4yLjPuRxP@bench.sobornost.net>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-ACL-Warn: Delaying message
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1a48c643071497d76528df08a5a10a45c
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/v4CAKLzM2VFyWf1sXsmzWvGTt-A>
Subject: Re: [Sidrops] 6486bis: referenced object validation
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 13:13:45 -0000

On 4 Dec 2020, at 12:17, Job Snijders <job@ntt.net> wrote:
> 
> On Fri, Dec 04, 2020 at 11:57:33AM +0100, Ties de Kock wrote:
>>>> However, validating these requirements for just CMS objects (as per
>>>> -03, instead of for CAs as well as per -00) leaves open the situation
>>>> where only part of the objects for a CA apply. When the ROAs are
>>>> correct, but the sub-CA is not, this can cause outages.
>>>> 
>>>> I don't have a preference on which way to go, but I would propose that
>>>> we treat invalidation (time, c.f. because of semantic errors) for both
>>>> CA certificates and other objects similarly.
>>> 
>>> I am not sure I follow, can you construct an example data set where the
>>> 'situation left open' you describe appears?
>>> 
>> 
>> Thanks for asking for clarification. I'll try to explain the scenario:
>> 
>> CA certificate with <AS64496, 192.0.2.0/24>
>>  * Manifest, containing
>> 	  * ROA: AS0, 192.0.2.0/24
>> 	  * sub-CA, resources: <AS64496, 192.0.2.0/24>
>> 	  	* Manifest, containing:
>> 			  * ROA: <AS64496, 192.0.2.0/24>
>> 
>> We have "all or nothing" for ROAs. I argue that a similar situation is present
>> for sub-CAs if the sub-CA expires.
> 
> You list two manifests, which means that software should:
> 
> round 1: process Manifest 1 containing AS0.roa + sub-CA.cer + crl
>    check if as0.roa and sub-CA.cer + crl are present and if the hashes
>    match
> 
> round 2: process Manifest 2 containing AS64496.roa + crl
>    check if AS64496.roa + crl are present and if the hashes match
> 
> Now let's image sub-CA.cer is present and the hash match, but turns out
> to be expired, it just invalidates sub-CA.cer and thus the software
> would never even open manifest 2, because sub-CA.cer is expired.
> 
> If sub-CA.cer is expired the ROA for AS64496 indeed will 'disappear' (as
> if never existed), leaving just the AS0 ROA. This is as the CA intended.

Compare that to:

Valid CA certificate with <AS64496, 192.0.2.0/24>
 * Manifest, with valid EE certificate, containing
   * valid CRL
   * ROA: AS0, 192.0.2.0/24, EE cert with 2020-12-01 expiration
   * ROA: AS64496, 192.0.2.0/25, EE cert with 2021-01-01 expiration

This results in a failed fetch when validated today.

Under our interpretation of -00, this manifest would be rejected, since all
objects on a manifest need to be valid (present, hash match, correct, non-expired)
for a fetch to succeed.

I would argue that to be consistent, this should not result in failed fetch, the
expired ROA should not apply, because this is what the CA intended.

What do you think the outcome should be?

Kind regards,
Ties