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

[Job Snijders <[e-mail]>]

On Tue, Mar 24, 2020 at 10:42:37AM -0300, Tim Bruijnzeels wrote:
> >> As I wrote before, I believe that a single mistake (withheld /
> >> unpublished object or even a bit flip) invalidating a whole
> >> repository,
> > 
> > Some nuance could be added: it depends on where the error in the
> > tree exists. If a top level manifest or CRL is hosted, indeed
> > everything underneath it should be tossed. But for instance when a
> > manifest 'at 2 levels deep', references a file that doesn't exist,
> > you only need to toss that specific manifest (at least). So, yes,
> > errors in the repository should result in the repository (or parts
> > of it) being considered inadmissible.
> > 
> > RPKI started out on the premise that an unencrypted transport
> > (rsync) was acceptable, because everything was signed and
> > cryptographically verifiable. Now we are in a situation where the
> > transport channel *is* insecure, and the data transmitted across it
> > is not properly verified. Validators are *knowingly* proceeding to
> > produce VRPs with incomplete, expired, and/or corrupted data.
> 
> With RRDP over HTTPS a lot of in transit / MITM issues are mitigated.

I'm not sure I agree - routinator, fort and octorpki are trivially
forced to use rsync if the attacker blocks TCP port 443.

> The RFC currently still says that invalid certificates should be
> accepted though. The thought at the time was that we have object
> security and people make too many mistakes configuring HTTPS. With
> Letsencrypt I believe this argument no longer holds.

Yeah, I recall the discussions ~ a year ago about that section of the
RFC. Unfortunately it turns out that we (as RP implementers) appear to
lack some checks in the RP software to be able to say we have 'object
security'. I also believe that the onus is on the CA operators to
correctly configure their HTTPS service. A misconfiguration of HTTP TLS
service of the RRDP publication point *should* result in the publication
point being dismissed (and perhaps use the local cache for what its
worth)

> First off I agree with Job that it would be better to disregard
> information that is known to be a partial version of the truth.

An additional check is needed: if one of the .roa files a manifest
references is corrupt (the MITM didn't delete strategically file, but
instead filled a .roa file with garbage), the anything referenced in
that manifest should be considered invalid.

an example, on my MITM box I did 'echo XX > fIeCcC8KpdJQd-olU2APdxNZkyA.roa',
so the .roa file exists, but the RP can see there is a mismatch between
the hash in the manifest and the hash derive from the
fIeCcC8KpdJQd-olU2APdxNZkyA.roa file. If a validator proceeds to output
VRPs based on the remaining (parseble) .roa files, you end up with an
incomplete set:

job@anton ~$ grepcidr 80.128.0.0/11 /var/db/rpki-client/openbgpd
	80.128.0.0/12 source-as 3320
	80.128.0.0/11 source-as 0
	80.128.0.0/11 source-as 3320
	80.144.0.0/13 source-as 3320
	80.152.0.0/14 source-as 3320
	80.156.0.0/16 source-as 3320
	80.157.0.0/16 source-as 3320
	80.157.8.0/21 source-as 3320
	80.157.16.0/20 source-as 3320
	80.158.0.0/17 maxlen 24 source-as 34086
	80.159.224.0/19 maxlen 24 source-as 2792

In the above eaxmple there should be ~ 19 VRPs in total,
fIeCcC8KpdJQd-olU2APdxNZkyA.roa contained 8 VRPs.

I suppose we must consider a 'partial withholding attack' equivalent to
a 'partially corrupted attack'.

In summary:

If a manifests references a non-existing file, or if there is a mismatch
between the hash listed in the manifest and the hash as derived from the
.roa or .crl files, the RP MUST consider the whole manifest invalid and
MUST not produce VRPs with the remaining .roa files.

Kind regards,

Job