Re: [Sidrops] 6486bis: Failed Fetches

[Tim Bruijnzeels <[e-mail]>]

> On 26 Aug 2020, at 12:25, Martin Hoffmann <[e-mail]> 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