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

[Job Snijders <[e-mail]>]

On Tue, Mar 24, 2020 at 03:20:09PM +0100, Martin Hoffmann wrote:
> Job Snijders wrote:
> > I'm not sure I agree - routinator, fort and octorpki are trivially
> > forced to use rsync if the attacker blocks TCP port 443.
> 
> At least Routinator does not fall back to rsync once it has
> successfully completed accessing the repository via RRDP once. I am
> open to strengthen this to not ever use rsync if there is a RRDP URI
> in the certificate. 

I'm interpreting the willingness to attempt to make MITM attack slightly
harder as an indicator that the described MITM partial
withholding/corruption attack scenarios are valid and problematic. :-)

I don't think a conclusion about the integrity of the DELTA snapshot can
be derived from the fetch mechanism itself: just because it was
retrieved over HTTPS doesn't mean there was no MITM attack. The
diginotar situation comes to mind, and crazier things have existed in
the wild.

The hashes used in the RRDP file format provide a degree of integrity
checking useful for the filetransfer itself, but don't seem to be meant
to verify any authenticity. This to me means that after downloading and
unpacking the RRDP snapshot, we still have to assume the data may have
been meddled with and some strategic files might have been either
corrupted or are missing.

The decision tree I see currently as 'safer' would be as following:

1) are all files referenced in a given manifest present?
2) do the hashes as listed inside the manifest match the contents of the referenced files?
3) is the CRL present and valid?
4) are all of the relevant signatures from not-revoked keys?

If the answer to any of the above questions is 'no', I think the leaf of
the tree at hand should be considered invalid to prevent tainting the
RFC 6811 validation procedure with incomplete data.

Kind regards,

Job