Re: [Sidrops] what to do when the CRL is hosed?

[Tim Bruijnzeels <[e-mail]>]

> On 24 Mar 2020, at 11:02, Tim Bruijnzeels <[e-mail]> wrote:
> 
> 
> 
>> On 23 Mar 2020, at 10:33, Stephen Kent <stkent=[e-mail]> wrote:
>> 
>> Tim,
>>> In general I agree. Which is why I mentioned the example of objects one might find published outside of the context of the RPKI repository, and *not* listed on a manifest. Such objects have yet to be invented but theoretically one can think of signed structures under an existing RPKI CA cert (e.g. using their own embedded EE) - which is shared out-of-band between parties. 
>> That's a very forward-looking perspective, one I had not considered.
>>> What I am suggesting is that we *could* update 6486 and make validation more restrictive regarding manifests:
>>> - all objects on a manifest must be present and accounted for (I agree with Job regarding partial withhold attacks)
>>> - all objects on a manifest need to be validated
>>> - objects that are not on a manifest can be considered invalid
>>> 
>>> This is in-line with the specifications defined in RFC 6481 (A Profile for Resource Certificate Repository Structure), which essentially says that all current objects must be published, and that no invalid objects may be published.
>> agree.
>>> Then, if the manifest is already a signed statement of everything that is current, at least regarding the currently defined object types, as defined in RFC 6481, then what is gained by checking that CA was also capable of generating a CRL - using the same authoritative key and publication method - that confirms that the objects that are current according to the manifest are indeed not revoked?
>> 
>> I agree that with strict Manifest processing, CRLs provide redundant info. But, by that argument, why bother checking to see if certs are expired, since that too is redundant in a strict Manifest processing scenario?
>> 
>>> Requiring the CRLs just feels like unnecessary brittleness to me (again in the context of RFC 6486). It creates multiple loci for bugs in CA implementations, and complicated error conditions that need to be checked by RPs. This is what I meant with the perhaps poorly chosen word 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy may seem like a good idea in general, but in this case it really only allows for the possibility of two conflicting signed messages. Thus it seems that this does not increase security, but provides more ways for things to break.
>> 

One more thought.. specifically on this:

>> redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences.


It's the same engine that signs both CRLs and MFTs. I believe that this increases the chance of bugs in signing, and orchestration of publication. And a failure in any of these cases can lead to bad results.



>> But, this strategy works only if one is flexible when responding  to an inconsistency between redundant pieces of info.
>> 
> 
> But, redundancy also introduces more moving parts which can break, and corner conditions to check.
> 
> Now it's fairly easy to get temporary inconsistencies. If CAs publish objects one by one, or in case rsync is used as a fetch mechanism (I believe that objects might change during an rsync 'session'). RRDP can resolve this, but only if CAs indeed publish their change set as a single delta.
> 
> But even with all that, my inner engineer would like to see as few moving parts as we safely get away with.
> 
> Failing that I believe one agreed on way to deal with each possible corner case between MFT and CRL is needed.




> 
> 
> 
> 
>> Steve
>> 
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops