[RPKI] transcient differences between rpki-client and routinator

[Tim Bruijnzeels]

Hi,

> On 10 Dec 2019, at 07:10, Martin Hoffmann <martin at nlnetlabs.nl> wrote:
> 
> Claudio Jeker wrote:
>> 
>> The reason why rpki-client did not accept this ROA is because the CRL
>> is bad:
>> 
>> rpki-client:
>> repository.lacnic.net/rpki/lacnic/8bb5ab6a-b91f-439b-bdfb-eb3c43470d36/17ccf2e528990c3d8b0172b3372656083e3ddf4f.crl:
>> bad message digest
> 
> Ah, right. Routinator doesn’t check the manifest hash of a CRL.
> 
>> Also why does routinator not fail for this ROA? I find it dangerous
>> to fail open in such a case. It mostly disables revocation.
> 
> Initially, this was an oversight on my part. Job made a good point
> about consistency between different implementations, so I will fix it.
> 
> However, I believe this is not a problem because there is no gain from
> using CRLs in RPKI. The purpose of the CRL is to protect against replay
> of revoked certificates or, in RPKI, revoked published objects. But
> because these objects are registered with their hash in the manifest,
> one would also need to replay an old manifest, which would then contain
> the hash of the old CRL and one could replay that, too.
> 
> Also, there is a weird circular dependency. The manifest’s EE
> certificate points to a CRL which I need to check in order for the
> manifest to be valid, but this CRL is not valid unless its hash on the
> very same manifest is valid.
> 
> The upshot is that, unless I am missing something, you can’t revoke a
> manifest with the CRL that is delivered with itself and, transitively,
> any object that is mentioned on the manifest.
> 
> If that were true, then CRLs only serve to make the system more
> brittle, increased its overhead, and make it harder to implement
> because of the requirement to revoke everything all the time.
> 

All of the above..

You can revoke the manifest EE if you really want to shoot yourself in an essential body part. You can also revoke other any other current object, but RFC 6481 (ResCert Repository Structure) says that the repository contains all current valid, non-revoked objects. So, you should not (normative language unclear) publish anything that is invalid, and you should publish everything that is. Also all objects refer back to a CRL, but there must (again normative language unclear) be only one CRL ever for a signing key - so here we have another locus for messing things up.


> But, this indeed is probably a discussion for SIDROPS and, as said, I’ll
> fix Routinator for now.

Historically - even before my time with RPKI so >10 years - there were no manifests. Just CRLs. Then people realised that this would be very insecure wrt replay. So the MFTs were invented. However, the use of MFT in validation left many things open to 'local policy', such as what to do w.r.t. stale, hash mismatch etc.

I never liked this, because it leads to confusion and differences between how RPs deal with things. All in all I wish that manifest would just be treated as the current signed list of everything, and then CRLs are not needed at all. They do not add security because they are signed by the same key that signs the manifest EE, they just introduce additional ways to break things - and they lead to knee jerk confusion. There was resistance to this stance when I brought it up ages ago (I forgot when) so I didn't push.. but we could rekindle the discussion.

As a side note: I believe the CRLs do add value if we were to publish any RPKI signed things outside of the RPKI repository. Like an RPKI signed object that I can give to someone else, or for 'naked' EE certificate which might be used to sign other things, such as RPSL (RFC 7909). We don't see those things in the wild yet, but there it would make sense that you can verify whether something has been revoked. But if we only used it for this purpose the CRLs could be much shorter, and could be long lived: just issue when needed and update the MFT hash. This would reduce some of the churn that we see in repos.

Kind regards
Tim



> 
> Kind regards,
> Martin
> -- 
> RPKI mailing list
> RPKI at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/rpki