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

From: Nathalie Trenaman <[email-masked]>
Date: Mon, 23 Mar 2020 11:34:43 +0100

Hi,

> Op 27 feb. 2020, om 10:50 heeft Tim Bruijnzeels <[email-masked]> het volgende geschreven:
> 
> Hi,
> 
>> On 27 Feb 2020, at 09:59, Robert Kisteleki <[email-masked]> wrote:
>> 
>> 
>> 
>> On 2020-02-26 18:39, Job Snijders wrote:
>>> I think the entire repository should be considered invalid if a single
>>> file is missing but was referenced in the manifest. One can't produce
>>> rules based upon false or incomplete data, and one can't protect against
>>> hijacks using unsigned data.
>> 
>> I'm not sure that'd be wise. Knowing you're missing something does not
>> invalidate the other bits that you can verify. Exactly what you keep
>> using can depend on what's missing (a CRL, a CA cert, a ROA, ...) though.
> 
> I am not saying that I have the complete answer here, but I think it's worthwhile to discuss this further - if the WG is willing to consider updates to the manifest RFC.
> 
> It gets complicated.
> 
> ROAs at the parent level have the ability to invalidate announcements by children that run delegated CAs. If their CA cert is missing, then this can impact ROV to the point that announcements by children are considered invalid.
> 
> In such cases it might be better to mark objects the ROA objects as invalid so that ROV yields not found. It is probably okay to recurse any other CA cert and use ROAs found under it. Probably, because probably they are more specific, and ROAs there would not invalidate covering, presumably, less specific announcements done by the parent (yes, lots of assumptions here). For BGPSec certificates things get more complicated, because at the MFT level they are indistinguishable from delegate CA certificates. Also BGPSec does not have a soft-landing, so invalidating certificates (rather than ROAs) might be quite harmful.
> 
> Note, I think this should be applied only to *missing* objects as that indicates either a failure to publish things properly, or possibly a partial withhold attack where the RP receives incomplete information. And even then, there may be ways to recover if an RP still has prior copies of all missing objects (check hash).
> 
> If objects are found and accounted for, but they turn out to be invalid, then I believe that other objects should not be impacted.
> 

I would still welcome discussion on this. For our Validator, we currently issue warnings if there is something wrong with the CRL. Some other RP (validator tools)  invalidate the chain, one ignores the CRL. This is not a good situation. 
From the mailing list, I didn’t see a clear consensus (yet?) for RP (validator tools). Any ideas? Thoughts? Did I miss something?

Thanks,
Nathalie

---

From: Claudio Jeker <[email-masked]>
Date: Mon, 23 Mar 2020 13:56:47 +0100

On Mon, Mar 23, 2020 at 11:34:43AM +0100, Nathalie Trenaman wrote:
> I would still welcome discussion on this. For our Validator, we
> currently issue warnings if there is something wrong with the CRL. Some
> other RP (validator tools)  invalidate the chain, one ignores the CRL.
> This is not a good situation. 
> From the mailing list, I didn’t see a clear consensus (yet?) for RP
> (validator tools). Any ideas? Thoughts? Did I miss something?
> 

I think the current discussion did show that RP tools should do the proper
validations and not skip steps.

As for rpki-client we still believe that doing strict checks of the
certificates is the right thing. rpki-client will exclude certs and the
data they protect if they do not validate (this includes not-valid before
and after timestamps of both the certificate and the CRL (if any)).
Additionally all hash values in mft files are verified and again objects
failing validation are excluded. The result is that only fully valid VRP
are exported and all others are skipped but a warning is logged. 

-- 
:wq Claudio

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Mar 2020 09:27:00 -0400

Nathalie,
> currently issue warnings if there is something wrong with the CRL. 
I think that is a very appropriate action.
> Some other RP (validator tools) invalidate the chain, 
that's a valid response, but one should remember that an out of date CRL 
is not invalid, it's just stale. Given the desire to balance robust 
operation security concerns, I think this may be overkill.
> one ignores the CRL. 
not a good response, and not conformant with the applicable RFCs!
> This is not a good situation. 
I agree that more uniform processing is desirable, but in the routing 
system the notion of local policy seems to be ingrained, so ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Mar 2020 09:33:20 -0400

Tim,
> In general I agree. Which is why I mentioned the example of objects 
> one might find published outside of the context of the RPKI 
> repository, and *not* listed on a manifest. Such objects have yet to 
> be invented but theoretically one can think of signed structures under 
> an existing RPKI CA cert (e.g. using their own embedded EE) - which is 
> shared out-of-band between parties. 
That's a very forward-looking perspective, one I had not considered.
> 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
>
> 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.
agree.
> Then, if the manifest is already a signed statement of everything that is current, at least regarding the currently defined object types, as defined in RFC 6481, then what is gained by checking that CA was also capable of generating a CRL - using the same authoritative key and publication method - that confirms that the objects that are current according to the manifest are indeed not revoked?

I agree that with strict Manifest processing, CRLs provide redundant 
info. But, by that argument, why bother checking to see if certs are 
expired, since that too is redundant in a strict Manifest processing 
scenario?

> Requiring the CRLs just feels like unnecessary brittleness to me (again in the context of RFC 6486). It creates multiple loci for bugs in CA implementations, and complicated error conditions that need to be checked by RPs. This is what I meant with the perhaps poorly chosen word 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy may seem like a good idea in general, but in this case it really only allows for the possibility of two conflicting signed messages. Thus it seems that this does not increase security, but provides more ways for things to break.

redundancy is often beneficial in security systems. it helps prevent a 
single error from having terrible consequences. But, this strategy works 
only if one is flexible when responding  to an inconsistency between 
redundant pieces of info.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Mar 2020 09:33:20 -0400

Tim,
agree.

Steve

---

From: Robert Kisteleki <[email-masked]>
Date: Mon, 23 Mar 2020 15:23:35 +0100

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)
>> 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.
> agree.

As I wrote before, I believe that a single mistake (withheld /
unpublished object or even a bit flip) invalidating a whole repository,
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?

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.

Robert

---

From: "Job Snijders" <[email-masked]>
Date: Mon, 23 Mar 2020 16:27:16 +0100

Dear all,

I'm observing the discussions in sidrops with increasing alarm. Taking stock of the current situation I see:

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

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.

> 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.

> one single object from a repo and poof, a whole subtree (forest...) is gone?

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.

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").

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.

> but leave the otherwise unaffected bits validated.

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.

If the validators are not going to be strict, what motivation exists for the CA operators to clean up their act?

If the validators are not going to be strict, are network operators supposed to just accept that the VRPs they feed into "invalid == reject" policies on their EBGP routers potentially are tainted? How will that convince anyone to deploy RPKI Origin Validation?

Kind regards,

Job

---

From: Rob Austein <[email-masked]>
Date: Mon, 23 Mar 2020 12:26:38 -0400

Unsurprisingly, I agree with Steve on this, particularly:

On Wed, 26 Feb 2020 12:03:33 -0500, Stephen Kent wrote:
...
> There are more cases one can analyze, but I think the basic approach
> is to stick with prior, validated CRLs and contact the CA that
> issued the questionable CRL, until the matter can be resolved.

As others have observed, there is no way the RP can know what the CA
intended when the data are inconsistent.  Furthermore, given that the
code which generates the CRLs is usually right next to the code that
generates manifests (they usually advance in lock-step), there's no
particular reason to assume consistency problems would be limited to
one or the other.

Trying to make sense out of an incoherent world is always going to be
part of the RP's job.  Falling back to older valid data has always
been part of the strategy for doing that in the RPKI, and at least the
first generation of RPKI validators all did that.  It's not perfect,
but it's better than an RP trying to guess which part of the protocol
to violate in an attempt to guess what a broken CA really meant.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 24 Mar 2020 10:42:37 -0300

> On 23 Mar 2020, at 12:27, Job Snijders <[email-masked]> wrote:
> 
> Dear all,
> 

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.

> 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, th…

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.

> If the validators are not going to be strict, are network operators supposed to just accept that the VRPs they feed into "invalid == reject" policies on their EBGP routers potentially are tainted?…

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.

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Tue, 24 Mar 2020 13:58:28 +0000

On Tue, Mar 24, 2020 at 10:42:37AM -0300, Tim Bruijnzeels wrote:
> > 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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 24 Mar 2020 11:02:38 -0300

> On 23 Mar 2020, at 10:33, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Tim,
>> In general I agree. Which is why I mentioned the example of objects one might find published outside of the context of the RPKI repository, and *not* listed on a manifest. Such objects have yet to be invented but theoretically one can think of signed structures under an existing RPKI CA cert (e.g. using their own embedded EE) - which is shared out-of-band between parties. 
> I agree that with strict Manifest processing, CRLs provide redundant info. But, by that argument, why bother checking to see if certs are expired, since that too is redundant in a strict Manifest processing scenario?
> 
> redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences. But, this strategy works only if one is flexible when responding  to an inconsistency between redundant pieces of info.
> 

But, redundancy also introduces more moving parts which can break, and corner conditions to check.

Now it's fairly easy to get temporary inconsistencies. If CAs publish objects one by one, or in case rsync is used as a fetch mechanism (I believe that objects might change during an rsync 'session'). RRDP can resolve this, but only if CAs indeed publish their change set as a single delta.

But even with all that, my inner engineer would like to see as few moving parts as we safely get away with.

Failing that I believe one agreed on way to deal with each possible corner case between MFT and CRL is needed.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 24 Mar 2020 11:05:09 -0300

> On 24 Mar 2020, at 11:02, Tim Bruijnzeels <[email-masked]> wrote:
> 
> 
> 

One more thought.. specifically on this:

>> redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences.

It's the same engine that signs both CRLs and MFTs. I believe that this increases the chance of bugs in signing, and orchestration of publication. And a failure in any of these cases can lead to bad results.

>> But, this strategy works only if one is flexible when responding  to an inconsistency between redundant pieces of info.
>> 
>

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 24 Mar 2020 15:20:09 +0100

> 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. 

Kind regards,
Martin

---

From: Job Snijders <[email-masked]>
Date: Tue, 24 Mar 2020 15:11:01 +0000

On Tue, Mar 24, 2020 at 03:20:09PM +0100, Martin Hoffmann wrote:
> 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

---

From: Oleg Muravskiy <[email-masked]>
Date: Tue, 24 Mar 2020 16:36:19 +0100

> On 24 Mar 2020, at 16:11, Job Snijders <[email-masked]> wrote:
> 

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Mar 2020 11:38:17 -0400

Tim,
> Now it's fairly easy to get temporary inconsistencies. If CAs publish objects one by one, or in case rsync is used as a fetch mechanism (I believe that objects might change during an rsync 'session…
yes, it is possible that a pub point may be updated during a sync 
operation, and thus an inconsistent set of objects will be retrieved. I 
would expect well-written RP code to detect this and try again, after a 
brief delay. For the rsynch case, one should create a new directory with 
all of the objects and then change the pub point to be the new 
directory, to make for a more "atomic" update procedure.
> But even with all that, my inner engineer would like to see as few moving parts as we safely get away with.
  if one changes to a model in which the Manifest is the sole arbiter of 
cert validity, i.e., if a cert is included in a current manifest and 
it's signature can be validated via cert path in the RPKI, the why 
bother with checking cert expiration? Same for ROAs. This is a slippery 
slope.
> Failing that I believe one agreed on way to deal with each possible corner case between MFT and CRL is needed.

How many corner cases are there?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Mar 2020 11:38:17 -0400

Tim,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Mar 2020 11:41:04 -0400

Tim,
> It's the same engine that signs both CRLs and MFTs. I believe that this increases the chance of bugs in signing, and orchestration of publication. And a failure in any of these cases can lead to ba…

Any bugs in the software that manages MFTs and CRLs is of concern. If 
one cannot manage to do both jobs correctly then maybe one ought not be 
running an RPKI CA.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Mar 2020 11:41:04 -0400

Tim,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Mar 2020 11:51:46 -0400

Job,
> diginotar situation comes to mind, and crazier things have existed in

Use of TLS, absent a CA compromise, protects against MITM attacks.

The CA compromise you cited (DigiNotar) was serious because of the Web 
PKI model, in which any trust anchor can issue a cert for any EE. Today, 
with the use of cert pinning and cert transparency logs, the likelihood 
of such attacks has very dramatically decreased in the Web PKI environment.

Can you provide an example of one of the "crazier things" (relevant to 
TLS and the Web PKI) hat have happened in the wild, and which are 
applicable here?

Steve

---

From: "Job Snijders" <[email-masked]>
Date: Tue, 24 Mar 2020 17:08:29 +0100

Dear Oleg,

On Tue, Mar 24, 2020, at 16:36, Oleg Muravskiy wrote:
> Your examples so far have showed that continuing with incomplete set of 
> ROAs after a withhold/manipulation on ROA objects might create 
> dangerous situation.
> 
> 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.

Good question. My intuition is that it is not entirely relevant what the file type is. My examples are indeed all ROA and CRL specific as the consequences are easier to demonstrate using the real Internet BGP tables in examples.

Treating ROAs differently than other types of files referenced in manifests may lead to pain somewhere down the road when it is discovered that these problems in fact didn't just apply to only ROAs or CRLs. If there happens to be a file type (now or in the future) where proceeding to extract data from subtrees is a safe choice to make, I think /that/ should be be the exception after it has proven to be a safe choice to do so.

The RPKI data does not lend itself for some kind of Solomon-Reed error correction. Manifests allow us to discover that /something/ is missing, but we have no idea /what/ is missing. If we don't know /what/ is missing, all bets are off. It is hard for me to imagine a scenario where the publication point's own ROAs are hosed but it'll still be safe to continue attempting to extract data from non-ROA objects from child certs / sub trees.

Should at some point there be 'business rule' interdependencies between various object types that may exist in the RPKI, and exceptions were made for ROAs but not for other file types - I suspect the complexity of the decision tree will become insurmountable.

Kind regards,

Job

---

From: "Job Snijders" <[email-masked]>
Date: Tue, 24 Mar 2020 17:54:09 +0100

Kent,

> Use of TLS, absent a CA compromise, protects against MITM attacks.

In a perfect world things are perfect? :-)

> of such attacks has very dramatically decreased in the Web PKI environment.

Yeah - I've seen tremendous improvements to Web PKI in the last few years. But still, CT logs are a reactive measure. In some countries operating systems may come with a compromised CA. A recent example: https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/

> TLS and the Web PKI) hat have happened in the wild, and which are 

I think there is no shortage of examples where the safety that should've been provided by TLS, was compromised because of a software defects or a misunderstanding in an implementation. This recently hit the news too: https://www.zdnet.com/article/lets-encrypt-to-revoke-3-million-certificates-on-march-4-due-to-bug/

I don't think this thread is not about whether TLS is perfect or not. I think most of us agree it is great we have an improved replacement for rsync in the pipeline. However, RPKI (as I understand it) was designed around being "self-contained" and the promise sort of seemed to be that regardless of the security (or insecurity) of the retrieval mechanism, a RPKI repository can and must be verified.

For the purpose discussion in SIDROPs, I think it is fair (and a necessity) to assume that MITMs are possible regardless of the repository retrieval mechanism in use.

Kind regards,

Job

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Mar 2020 10:57:11 -0400

> Kent,
BTW, my first name is Steve.
> In a perfect world things are perfect? :-)
Those of us who pose as security professionals distinguish between the 
security offered by a correct implementation of a protocol and 
associated crypto, vs.  buggy implementations, poor choice of crypto 
algs, etc.  If you are concerned about the security quality of a TLS 
implementation, then you should be _very_ concerned about the quality of 
the RPKI RP software, based on what we have been hearing!
> Yeah - I've seen tremendous improvements to Web PKI in the last few years. But still, CT logs are a reactive measure. In some countries operating systems may come with a compromised CA. A recent example:https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/

CT logs also are designed to deter mis-issuance by trust anchors, and 
facilitate remediation when mis-issuance is detected.  In that respect 
they seem to have been effective. Deterence is not reactive. (It's a 
pity that the authors of the CT docs have done a poor job of clearly 
explaining the purposes of the system, but ....)

If you operate in a country where the government can tampoer with the 
version of the OS you use, then none of the security measures we can 
provide via the RPKI will prevent a wide range of attacks on the RPKI 
data retrieved or published by the ISPs in that country. So, that seems 
to be a red-herring in the context of this discussion.

The ZDnet article your cite is analogous to the OS issue; the local 
government could act as a MITM for published and downloaded RPKI data. 
So, for downloaded data the local ISPs could be denied access to current 
RPKI data, or receive only partial RPKI data, which hurts them and their 
customers. For uploaded data, other ISPs could see only partial or old 
RPKI data from the affected, local ISPs. In that case the principal 
effect would seem to be to disadvantage the local ISPs and their 
customers.  So, again, if your local government is allowed to mess with 
you as an ISP, you're screwed, but their ability to adversely affect 
origin authentication info for other ISPs is ??

> I think there is no shortage of examples where the safety that should've been provided by TLS, was compromised because of a software defects or a misunderstanding in an implementation. This recently hit the news too:https://www.zdnet.com/article/lets-encrypt-to-revoke-3-million-certificates-on-march-4-due-to-bug/
>
not a great example, IMHO. The CA back end bug, if not quickly detected 
and remedied, would have caused web sites to not have up-to-date certs, 
which would have resulted in warnings to users (via their browsers). 
Again, this is not a TLS issue, per se, and it did not undermine the 
security afforded by TLS; it potentially caused some level of DoS for 
the affected servers, but DoS protection is NOT a security feature if TLS.
> I don't think this thread is not about whether TLS is perfect or not. I think most of us agree it is great we have an improved replacement for rsync in the pipeline. However, RPKI (as I understand…

Well, as one of the principle architects of the RPKI, I can tell you 
that it was designed with the "principle of least privilege" as a major 
security feature.  In the RPKI context this

     - limits the damage than any individual ISP can inflict as a result 
of local errors in generating certs and ROAs, whether due to software 
bugs, operator error, or local government influence

     - limits the damage that can occur if a repository is attacked

It also was intended to be independent of the Web PKI and its trust 
model. Using RRDP with certs issued by Web PKI trust anchors violates 
the last goal, but the effect seems to be equivalent to attacks on a 
repository. MFTs were designed (again, I was helped defined the concept 
of Manifests) to deal with active attacks on pub point data, 
irrespective of the mechanisms used to distribute that data.

So, I think discussing MITM attacks is a distraction, unless we have 
examples of how such attacks can affect RPs in ways different from 
attacks on repositories. Maybe re-reading RFC 8211 would be useful, as 
it tries to analyze a range of possible "adverse actions"  by CAs or 
repository managers in the RPKI context, and discusses how RPKI 
mechanisms are intended to detect/counter these actions.

Steve

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 31 Mar 2020 11:42:00 -0400

first, apologies for getting back around to this so late :(

On Thu, Mar 26, 2020 at 10:57 AM Stephen Kent
<stkent=[email-masked]> wrote:

> So, I think discussing MITM attacks is a distraction, unless we have examples of how
> such attacks can affect RPs in ways different from attacks on repositories. Maybe re-reading
> RFC 8211 would be useful, as it tries to analyze a range of possible "adverse actions"  by CAs or
> repository managers in the RPKI context, and discusses how RPKI mechanisms are intended to
> detect/counter these actions.

In the case of the incident which started this thread we ended up
publishing part of the content a
repository needs to publish such that the relying parties can verify
properly that the content in the
repository is correct/valid/usable. The discussion then went along a path like:
   1) "well... maybe we shouldn't have belt and suspenders?" (manifest AND crl)
   2) "what happens if we don't publish this pesky CRL? and rely only
on the manifest?"
   3) "what if we don't publish the manifest and only rely on the CRL?"
   4) "CRL + Manifest has made 'rp software' hard/buggy"

In the world where the protections specified for RPKI exist:
  1) self contained content protection (roa / ee-certs / etc are
packaged securely)
  2) crl signed and available in the repository for revocation actions
on objects in the repository
  3) manifest signed and listing all objects of interest in the repository

Steve (kent!) is right mitm is harder to see as a threat.
  "All objects you get are signed by a ca-cert which is signed by the
root.. which is in the list of TAL you have. You can't have missing
objects and you cant' remove objects without affecting the signed
manifest"

In a world where we remove one/some of the protections:
   A) no more manifest
   B) no more crl
   C) both

I think mitm problems are much harder to detect/deal with :(
It sounds like WG folk (RP users and RP/CA software authors) are
asking for guidance on handling the problem(s) discussed here.
It sounds, to me, like a chat at the upcoming interim meeting would be
a great place to start that with some slideware and a proposal to use
as kindling.

I think the shape of the conversation is roughly:
  "What would be the effect (on the routing system) for RelyingParties
if we decided to be less strict about CRL existence?"
  "What would be the effect (on the routing system) for Relying
Parties if we decided to be less strict about repository contents vs
Manifest contents?"
  "What happens to the routing system if the manifest and crl are
either/both 'broken' in a repository?"

I don't think it matters much to the routing system where the breakage
occurs (my repository or RIPE/ARIN/etc) certainly there's more fallout
from ARIN/RIPE/etc, but... you can't get to me either way :)
(possibly) until repair and propogation.

Thoughts on some slideware and discussion?
Did I about capture the meat of the sandwich here?

-chris
co-chair but asking as a regular chemical engineer at this party.

---

From: George Michaelson <[email-masked]>
Date: Wed, 1 Apr 2020 08:20:53 +1000

I think you did capture the spirit.

I would remind people that *all* the products in a repository are
signed objects. To arrive at a state where a manifest is "wrong"
demands two things: it doesn't reflect some real-world situation
regarding contents of the repository *and* its signed by keys you can
validate back to a trust anchor. If you cannot validate the manifest,
then its not "wrong" its forged, or invalid cryptographically.  To me,
a  "wrong" manifest checks out cryptographically but somehow is not
coherent with the state of the repository. If objects are on the
manifest but cannot be fetched, you are probably suffering either from
hiding of objects, or a transitional state of publication. If objects
can be found which are not on the manifest, you may be seeing
artifacts which are not defined as critical (must be found) or, the
manifest has not yet been updated.

There are potentially transitional states in the production of a large
repository under eventually consistent production (e.g. multiple
asynchronous cooperating processes, dual-redundant signing models)
where what can be fetched and what is on manifest do not align.  If we
wish to demand that the manifest and a given state of the repository
*always* align, we need to formalise that in a way which makes it
clear we publish repository state in as close to atomic-update as
possible. (copying a repo to a new dir, modifying the contents of the
new dir, and (re)publishing the change through the rename() call in
UNIX is one such model)

A missing manifest is not a "wrong" manifest -its a sign of data being
hidden from you either because of transitional effect in publishing
the repository, or for persisting state a problem in the repository
(diskfull?) or, production systems, or a MITM attack. Which do you
think is actually most likely at this current time? This is no
different to a missing CRL in that regard. Which do you think is the
most likely reason, because you cannot a-priori know that its a MITM
attack, or a failure in networks, or storage systems, or production
systems.

During the early design phases of the system, we determined that since
the products were all cryptographically signed, there was no strict
requirement for cryptographic protections on transport. If that
decision needs to be revised I think it should be done in standards
work, here, as a discussion. I do not yet see a document which says
that. I don't see formalisms which go to a normative change in SHOULD
to MUST on this.

So these comments aside, my plea is that people clearly state when
they say "wrong" or "bad" if they mean that it is cryptographically
valid, but does not align with some external reality, or some other
meaning. (Which btw, is complex because the part which none of this
can adequately capture is *intentionality* -Just because you think a
publication of RPKI state is nonsensical does not mean its not
intentional)

Attack models need to state clearly how they acheve the state. An
attack on the integrity of the manifest needs to explain coherently
how it creates a manifest which checks out cryptographically, and yet
hides or legitemates something which should not exist. They also need
to explain how the specific attack on the manifest in these situation
outweighs other considerations: If they have the keys, then surely the
attack vector is to make validly signed things which cannot be
detected as an attack?

-George

---

From: Di Ma <[email-masked]>
Date: Wed, 1 Apr 2020 11:02:48 +0800

Yes.

Although the RPKI provides object-oriented security yet the validity of an object relies on a trust chain, any wrong node of which would cause failure.

So-called “wrong” MFT will bring about trouble no matter it is rooted from transport or RPKI provisioning side.

Situations could be complicated as analyzed in section 2.2 of RFC 8211 in terms of adverse actions on MFT but RFC 6488 leaves much to RP to decide.

BTW, in RFC 8211 we authors differentiate if the attacker have got access to the private key of the INR holder, trying to give a threat mode.

So it is right time to reconsider the requirements posed on RP in case of “wrong” MFT. 

Di

> 2020年4月1日 06:20，George Michaelson <[email-masked]> 写道：
>