Re: [Sidrops] 6486bis: Failed Fetches

Tim Bruijnzeels <tim@nlnetlabs.nl> Wed, 26 August 2020 12:25 UTC

Return-Path: <tim@nlnetlabs.nl>
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 47BFC3A1245 for <sidrops@ietfa.amsl.com>; Wed, 26 Aug 2020 05:25:38 -0700 (PDT)
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 (1024-bit key) header.d=nlnetlabs.nl
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 lSi8-3G9FY0R for <sidrops@ietfa.amsl.com>; Wed, 26 Aug 2020 05:25:37 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 E1FF53A1243 for <sidrops@ietf.org>; Wed, 26 Aug 2020 05:25:36 -0700 (PDT)
Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:a56f:53c5:813:7a44]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2BC7E18C97; Wed, 26 Aug 2020 14:25:34 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598444734; bh=ZnvPg+i6PW0wvgO8F5YG6Zry/+iOeXOFeSBg+bfvGf0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hPFUlU5ClDeJrZzuFj0N32k/2mqAgE8mVx6FJF+cKs/mqriwekWhr+RWgauORfkVo XiuF7Pjhi61LqAIJd2cCdmxpvu65+GlDljwpU9hEAJScArzTY1nYOiyBKn+3+0toNV yRQCgFUNxfIPhEQ8tTof60hBULN5ocgjaNVswwJw=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <20200826122539.52493813@glaurung.nlnetlabs.nl>
Date: Wed, 26 Aug 2020 14:25:33 +0200
Cc: Stephen Kent <stkent@verizon.net>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <11EA0403-E4F3-45B0-9231-1CD4DFB0690E@nlnetlabs.nl>
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net> <20200818083659.1922a98c@grisu.home.partim.org> <6cebcc89-3e07-8a85-3813-b4ae9887d119@verizon.net> <20200826122539.52493813@glaurung.nlnetlabs.nl>
To: Martin Hoffmann <martin@opennetlabs.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Mldz5a43kPPotslF9bpNz10rysk>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Wed, 26 Aug 2020 12:25:38 -0000


> On 26 Aug 2020, at 12:25, Martin Hoffmann <martin@opennetlabs.com> wrote:
> 
> Hi Steve,
> 
> looks like you forgot to include the mailing list, so I’ll keep the
> quote in full.
> 
> Stephen Kent wrote:
>> Martin,
>>> Stephen Kent wrote:  
>>>> 
>>>> Are you positing the case where the cache contains an expired ROA
>>>> for a CA instance, and a fetch that would have replaced the
>>>> expired ROA fails?  
>>> No, I am talking about a case where the ROA can be fetched
>>> successfully and matches the manifest hash, but its EE certificate
>>> is expired. Section 6.4 says that "if [files] fail the validity
>>> tests specified in [RFC6488]", the fetch has failed. Thus, the
>>> expired EE certificate in the ROA fails the complete fetch of all
>>> objects associated with the CA.  
>> Thanks for the clarification.
>>> So, not replacing an expired ROA in a publication point makes the
>>> entire CA not update anymore. I.e., any other objects that now
>>> expire cannot be replaced until that ROA is also replaced.  
>> "not update anymore" is not how I would state the result. This fetch 
>> will fail. Because a failed fetch will be reported to the RP
>> operations staff, hopefully they will contact the cognizant entity
>> for the pub point in question, causing the error to be fixed. Them a
>> subsequent fetch can succeed.
> 
> That seems like an overly optimistic approach to the issue. Assume the
> problem is created by a bug or, worse, design oversight in the CA
> software. The turnaround from discovering the issue to deploying a fix
> can easily be weeks with some vendors. During all that time, not only
> can no ROAs be updated and may child CA certificates slowly expire, the
> entire CA’s data will not be available at all for any newly deployed
> relying parties. With containerised deployment, this is quite a serious
> issue.
> 
> As a consequence, this approach will make the routing system less
> secure for, I’d like to argue, no actual gain.

I believe that manifest should tell me that I have *all* *latest* objects. If there is stuff missing then rejecting the publication point is fine by me. But I have a problem with doing the same if invalid objects are found.

In addition to what Martin said. This makes the system very brittle w.r.t. changes in resources. Suppose that I had received 10.0.0.0/24 and 192.168.0.0/24 on my certificate issued to me by my parent, and I created ROAs for both. Now my parent pro-actively removes 10.0.0.0/24 from my certificate but they have neglected to tell me in time. I see no reason why my ROA for 192.168.0.0/24 should now be considered invalid. And I remember that we had discussions in this WG advocating that separate ROAs are created for each prefix, precisely to prevent this kind of fate sharing.

Tim