Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

[Tim Bruijnzeels <[e-mail]>]

Hi,

a few more comments.. after this I think it's better (from my end) to discuss tomorrow in the working group.


On Jul 24, 2014, at 2:35 PM, Stephen Kent <[e-mail]> wrote:

> Tim,
> 
>> ...
>>>> 
>>>> The first approach has my strong preference. I believe it's simple to explain and implement, effective against both concerns, and I do not see any security issues with it. The change boils down to this: when doing top-down validation, just accept the *intersection* of resources listed on a certificate, and its parent. The idea of keeping track of resources explicitly is not new: we already have this when using 'inherit'. We have running code in our validator for this. It took us a day to implement this. The feature is off by default of course, but it's enabled without problems on a public instance that we're running: http://localcert.ripe.net:8088/
>> 
>> What I forgot to mention above is that we do issue warnings on over claiming certificates. So this is visible, although so-far we have not seen these warnings in the RIR production repositories.
> Can you says what tests you perform and how will they change if we adopt a relaxed path validation alg?

pseudo code:

Strict:
  parentresources = parentcertificate.getresources
  childresources = certificate.getresources
  if (parentresources contain childresources) {
     accept childresources
  } else {
     reject
  }

Relaxed:
  parentresources = parentcertificate.getAcceptedResources
  CLAIMED_childresources = certificate.getresources
  if (parentresources contain CLAIMED_childresources) {
     accept CLAIMED_childresources
  } else {
     warn about over-claimed resources
     accept remaining
  }

As mentioned in the other part of this thread: this applies to accepting resources on a certificate, i.e. in connection to a key. For ROAs we do insist that *all* resources that appear in ROA prefixes are accepted on the EE certificate used to sign the ROA. For MFT inherit is mandatory so it's irrelevant. For GBs also use inherit, so here the contact would only be accepted for remaining resources. For router certificates the router key would only be associated with accepted ASNs.



>>> More to the point, we all agree that it is very bad for an RIR or NIR to issue a cert
>>> that would break the current validation algoroithm. In a prior message I suggested several
>>> checks that I thought every CA operating should perform to detect and avoid such errors.
>>> Has RIPE been performing check such as these? Might adoption of relaxed validation rules
>>> minimize the perceived need to perform such checks, i.e., encourage sloppiness?
>> 
>> It is not my intention, and I believe it's safe to say that it's not the intention of others, to encourage sloppiness, but to minimise impact and improve resiliency if an error does occur.
> I understand this motive, but we have seen many examples over time where accepting non-conforming
> data results in progressive degradation of implementations. This is why the RPKI specs mandate
> RP enforcement of the criteria that CAs are supposed to follow in issuing certs.  This is in
> contrast to the normal PKI specs which mandate CA cert generation rules, but do no generally
> require RPs to check that certs have been generated consistent with these rules. In the Web PKI 
> context, this has resulted in a lot of "broken" certs being issued, and then accepted by RPs, 
> with not so great results. So, I think it is hard to increase resilience yet maintain sufficient
> feedback to CAs to help encourage standards compliance.

And I understand that a whole tree being invalidated is a pretty strong motivator for fixing stuff. But I find the operational impact and liability of this happening at the top of the hierarchy disproportionate. Therefore I am advocating a model where the impact is limited to INRs in question. In my opinion that is still bad enough to motivate fixing things.

Very practical example: if we stuff up our TA certificate now we invalidate 2000+ members. With relaxed validation we would only affect a few. And yes, this is still bad enough that we would want to fix it ASAP.

>> Speaking for our own CA implementation. We have code in place to ensure that we cannot create over-claiming certificates. We also have code to re-issue products as needed when resources are shrunk (e.g. omitting certain ROA prefixes when the resources are no longer held by the CA). However, there are a lot of moving parts here, and no software is without bugs. This problem gets worse when certificates are received from, or issued to third parties. In our current software we manage all CAs in our hierarchy locally, so we *know* when something changes and we can do the above. When dealing with 3rd parties there may be a significant time that parent and child are out of sync about the resources held by the child.
> see my question above about how you ensure that certs don't over-claim and how the mechanisms
> would change if path validation were relaxed.

We currently rely on *pro-active* rules in our software that prevent this. But I have no issues with setting up *re-active* self-monitoring on top of this. And I have no problems with appropriate text instructing CAs that they SHOULD or even MUST do the latter.

>>>> The second approach in section 4 was presented at the last IETF (draft-barnes-sidr-tao). Essentially it allows for transfer signalling through an up-down like protocol. Technically this approach can help to deal with transfer issues (2).
>>> The cited approach approach is designed expressly to deal with transfer issues, not with the
>>> more general problem of errors by CAs. One ought not conflate these two issues.
>> 
>> Okay, fair enough. As long as it's clear that this is the scope.
> The first sentence of the Abstract for TAO says:
>    This document defines an extension to the rpki-updown protocol to
>    provide support for transferring Internet Number Resources from one
>    INR holder to another.  
> 
> That seems pretty clear. 

That is indeed pretty clear. It is cited under 'alternative approaches' though, so maybe we would do well to make it clear here that this approach is designed to address one specific set of problems (i.e. transfers), or leave it out.