Re: [Sidrops] 6486bis: Failed Fetches

Tim Bruijnzeels <> Wed, 26 August 2020 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47BFC3A1245 for <>; Wed, 26 Aug 2020 05:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lSi8-3G9FY0R for <>; Wed, 26 Aug 2020 05:25:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1FF53A1243 for <>; Wed, 26 Aug 2020 05:25:36 -0700 (PDT)
Received: from (unknown [IPv6:2001:981:4b52:1:a56f:53c5:813:7a44]) by (Postfix) with ESMTPSA id 2BC7E18C97; Wed, 26 Aug 2020 14:25:34 +0200 (CEST)
Authentication-Results:; dmarc=fail (p=none dis=none)
Authentication-Results:; spf=fail
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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.\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Wed, 26 Aug 2020 14:25:33 +0200
Cc: Stephen Kent <>, SIDR Operations WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Martin Hoffmann <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Aug 2020 12:25:38 -0000

> On 26 Aug 2020, at 12:25, Martin Hoffmann <> 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 and on my certificate issued to me by my parent, and I created ROAs for both. Now my parent pro-actively removes from my certificate but they have neglected to tell me in time. I see no reason why my ROA for 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.