Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com>
Date: Tue, 24 Mar 2020 10:42:37 -0300
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B072025-68C5-4E62-9466-5122D483F691@nlnetlabs.nl>
References: <20200224151532.GD19221@vurt.meerval.net>
 <20200224211531.GB60925@vurt.meerval.net>
 <20200225090338.10464b1a@glaurung.nlnetlabs.nl>
 <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net>
 <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl>
 <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net>
 <253D1ED7-52D8-4A00-9D69-095E61D09C9F@nlnetlabs.nl>
 <db920115-e188-700f-ceb2-08cd2996046a@verizon.net>
 <3a683da4-42f9-28c6-f0dd-4d11d3c67857@ripe.net>
 <4fe26a30-4a08-41a5-be7f-0c5997230d0a@www.fastmail.com>
To: Job Snijders <job@ntt.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/mDbjP9AYWBu4SGQ_mry-8J2K88M>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
Precedence: list



> On 23 Mar 2020, at 12:27, Job Snijders <job@ntt.net> wrote:
>=20
> Dear all,
>=20
> I'm observing the discussions in sidrops with increasing alarm. Taking =
stock of the current situation I see:
>=20
> 1) failure to produce consistent output across multiple validators =
based on the current specs
> 2) failure to produce software updates which address the reported MITM =
scenarios
>=20
> One can argue "well, the specs did not explicitly mentioned what to do =
in scenario X Y Z", but even if the specs don't give precise guidance on =
what to do, I do not believe that the specs anywhere specify that =
insecure behaviour is acceptable. And even /if/ the specs granted =
"permission" for sloppy validation strategies, I'd expect any software =
developer producing 'security software' to deviate from such specs and =
implement validation strategies which are as secure as possible.
>=20
> On Mon, Mar 23, 2020, at 15:23, Robert Kisteleki wrote:
>> On 2020-03-23 14:33, Stephen Kent wrote:
>>>> 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
>>>>=20
>>>> 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.
>>=20
>>> agree.
>>=20
>> As I wrote before, I believe that a single mistake (withheld /
>> unpublished object or even a bit flip) invalidating a whole =
repository,
>=20
> 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.
>=20
> 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. =
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.


>=20
>> and as a consequence everything that could be validated under it, is =
a
>> way to high price to pay. It also makes attacks much easier: =
withholding
>> one single object from a repo and poof, a whole subtree (forest...) =
is gone?
>=20
> I'd be very hesitant to use absolutes such as "the price is way too =
high". The alternative is to allow for a number of MITM attack vectors. =
What is the cost of those? I have MITM examples running in my lab with =
routinator, rpki-client, fort, and ripe ncc's validator where partial =
withholding attacks are trivial and successful. The result of those MITM =
attacks is hard-to-troubleshoot network outages.
>=20
> Strategically hiding a select few ROAs can easily result in large =
scale outages because the attacker can make "RPKI Valid" announcements =
flip to "RPKI Invalid": this is worse than if the validator would've =
thrown out the manifest (things would've gone from "Invalid" to =
"Not-Found").
>=20
> Performing the RFC 6811 Origin Validation procedure on an *incomplete* =
set of data is worse than not doing RFC 6811 at all. If RPKI validators =
allow flipping announcements from Valid to Invalid, that goes against =
the premise under which we designed RPKI to be incrementally deployable. =
We taught this industry that deploying RPKI would be safe.

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.

As said above, RRDP with HTTPS + real certificates will help. At least =
it will make it clear if data is being tampered with.

Finally, I did not say that data must be disregarded if things cannot be =
fetched. If the RP has all the objects in its local cache it can use =
them. If the MFT and CRL are still current and valid and local copies =
exist for all objects as identified by their hashes (such object change =
far less frequently) then one can just use them.


>=20
>> I believe a more nuanced approach is needed, like if there's a =
problem
>> on a particular validation path (a cert is missing or has an error) =
then
>> invalidate that path, if a CRL is missing then warn but use a stale =
one,
>> but leave the otherwise unaffected bits validated.
>=20
> I'm not sure you weigh the power of partial withholding attacks as =
severely as I do. As mentioned before: stricter validator on the RPKI =
Cache Validator side of the house will put the onus on RPKI CA =
Publication points to run a tight ship. I believe this to be appropriate =
because there are far less CA operators than there are RP operators.
>=20
> If the validators are not going to be strict, what motivation exists =
for the CA operators to clean up their act?
>=20
> If the validators are not going to be strict, are network operators =
supposed to just accept that the VRPs they feed into "invalid =3D=3D =
reject" policies on their EBGP routers potentially are tainted? How will =
that convince anyone to deploy RPKI Origin Validation?

I agree that a partial withhold incident (involuntary) or attack - if =
detected should lead to disregarding things. If not one can cause =
invalids with serious impact, whereas a disregard would also be painful =
but it would lead to 'not found' instead.

>=20
> Kind regards,
>=20
> Job
>=20
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops