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

[Oleg Muravskiy <[e-mail]>]

> On 24 Mar 2020, at 16:11, Job Snijders <[e-mail]> wrote:
> 
> 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

Job,

Your examples so far have showed that continuing with incomplete set of ROAs after a withhold/manipulation on ROA objects might create dangerous situation.

Are there scenarios where withholding / making invalid a certificate, for example, leads to a similar danger?

I wonder if this is specific to ROA objects only, and whether we should treat them differently. If it is, then we could “ignore” all published ROAs at the specific publication point, but continue validation to child certificates and their sub-trees.

Oleg