Re: [Sidrops] 6486bis: Failed Fetches

[George Michaelson <[e-mail]>]

FYI we fully intend resubmitting RTA, we were waiting for the second
implementation (the work Martin is doing) to have input of merit to
spin the new version. It would be plausible to resubmit for the
November IETF. Two running code!

We designed RTA to be complete outside of a repo, so it can be used
privately between B2B partners. Not that its things cannot "be" on the
manifest, but that there is no dependency on the repo framework beyond
the TA, because the passed data is the chain for validation. This
matters to people who want to conduct activity outside of the BGP
validation problem, which is an 'all data needed' problem. B2B uses of
RTA are not directly about all data. Its different. (provisioning is
typically the use case here and the intent is to show the request to
route, originate, provision is valid, because control of the resource
can be demonstrated. its inherently a one-to-one conversation)

RTA objects have an OID, are in the registry of types. So there is a
meta-question implicit here, that the set of OID which can be
referenced from a Manifest is NOT bound, and CAN increase, so
validators have to be written in a way which expect to deal with
unknown signed things: The system is not closed, and there will be
others in future. I think the validation of a manifest MUST NOT fail
simply because unknown objects exist on the Manifest, especially if
the OID lies in the arc of RPKI definitions.

Martin's question is also on the other side of the deal: If a manifest
is showing a repository is incomplete, does it cause formal
invalidation of all things in the manifest, which has potential to
make validation of the 'complete' chain we send in RTA not work
because now, an object on the RTA validation path is questioned for
other reasons.

I tend to the view that only things which invalidate the certificates
matter, ROA or other elements are not contributing to the validity of
the RTA.  This is because they are not material to the validity of the
object. If it was a 'whole repo' problem I could argue otherwise. It
is not. It is inherently constrained.

Specifically Missing CRL.. I have more concerns about. That would mean
we cannot authentically deny the objects being validated.

-G

On Tue, Aug 18, 2020 at 4:37 PM Martin Hoffmann <[e-mail]> wrote:
>
> Stephen Kent wrote:
> >
> > Are you positing the case where the cache contains an expired ROA for
> > a CA instance, and a fetch that would have replaced the expired ROA
> > fails?
>
> No, I am talking about a case where the ROA can be fetched successfully
> and matches the manifest hash, but its EE certificate is expired.
> Section 6.4 says that "if [files] fail the validity tests specified in
> [RFC6488]", the fetch has failed. Thus, the expired EE certificate in
> the ROA fails the complete fetch of all objects associated with the CA.
>
> So, not replacing an expired ROA in a publication point makes the
> entire CA not update anymore. I.e., any other objects that now expire
> cannot be replaced until that ROA is also replaced.
>
> You could argue “Don’t do that, then” but this approach doesn’t make
> the RPKI more robust but rather makes it break more easily on simple
> oversights.
>
> > > This rule also blocks skipping objects of types I don’t know or care
> > > about. I will have to at least do signed object validation on them,
> > > which means reading and parsing them and then do signature
> > > validation. If that is intended, I think this should be called out
> > > explicitly in the document.
> > If a manifest points to objects that are not CRLs, certs, ROAs, etc.,
> > then it is in error.
>
> How do you introduce new object types in this case? There will always
> be relying parties that run old software that doesn’t know of them. You
> rather have to assume that objects of unknown types are signed objects
> with unknown content. If you do that, the current draft stipulates that
> you have to read, parse, and validate them -- and then throw away the
> content.
>
> This still means that all object types added to the RPKI must be signed
> objects. Whether that is okay or not, I don’t quite know.
>
> > But, your question seems to be what processing
> > has to be performed on the files contained in an apparently valid
> > manifest, right? Section 6.4 and RFC 6488 defines the tests to be
> > performed, and 6.4 explicitly cites 6488. What additional info do you
> > feel is needed here?
>
> I would like the document to explicitly state how to deal with object
> types appearing on a manifest that a replying party does not know. If
> nothing else then to make the document more helpful for implementers.
>
> > > But I’m not even sure it provides any benefit. I, say, I am
> > > validating a resource tagged association (RTA, [0]), I don’t care
> > > about the ROAs at all. Does the RTA become invalid because a CA
> > > somewhere in the validation chain had an expired ROA?
> >
> > I have not examined the RTA ID, and it's an expired draft, so ...
>
> RTA validates signed objects distributed via alternative means using
> the PKI published as part of the RPKI. I.e., one of the CA
> certificates published via the RPKI has issued the EE certificate used
> in that signed object.
>
> In order to validate that object, I do not need to look at any ROAs or
> GBRs, only certificates, CRLs, and manifests.
>
> Should validation of that object fail if there is an expired ROA
> published by one of the CAs along the validation chain?
>
> Kind regards,
> Martin
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops