Re: [Sidrops] [WG ADOPTION] draft-yan-sidrops-roa-considerations - 04/16/2021

[Job Snijders <[e-mail]>]

On Tue, Mar 30, 2021 at 01:24:32PM +0200, Tim Bruijnzeels wrote:
> > On 30 Mar 2021, at 12:00, Job Snijders <job=[e-mail]> wrote:
> No, the publication server does not validate content. See RFC 8181:
> 
> 5.  Security Considerations
> 
>    The RPKI publication protocol and the data it publishes use entirely
>    separate PKIs for authentication.  The published data is
>    authenticated within the RPKI, and this protocol has nothing to do
>    with that authentication, nor does it require that the published
>    objects be valid in the RPKI.

Interesting! Today I learned something :-)

I thought the *Repository* server is expected to validate objects
submitted by its repository clients, at least that is how I interpret
the implementation of some RPKI CA software.

The text in the Security Considerations seems at odds with the existence
of the 'bad_cms_signature: Bad CMS signature' error code. How can a bad
CMS signature be detected if the receiving Repository is not validating?

I'd still suggest to expand on the 'safeguard' language to avoid ROA
creation when resources listed in eContent are not contained by
resources listed as subordinate on the EE cert. Perhaps the authors of
the draft at hand can elaborate on what was intended with 'safeguard'?

> That being said.. as yet another aside..
> 
> I have been thinking of proposing extensions to the publication
> protocol (RFC 8181) to make Publication Servers somewhat more
> responsible. For example they could enforce quota both in terms of
> number of files, and size. They could also verify objects, e.g. only
> allow known types, and only allow objects which at least parse. But
> there is a potential issue then with bugs in verification code. Also,
> if this is done for security then it may not matter because malicious
> CAs could 'just' run their own publication server, until they might be
> revoked by an angry parent CA. Still... I think this is worth a
> (separate) discussion. Raising the barrier to abuse and mistakes seems
> like a good idea.

These are excellent suggestions, I agree an 'Object too large' error
code (and others) would be helpful.

> > I would suggest:
> > 
> > """
> > 3) A safeguard scheme is essential to protect the process of ROA
> >   issuance. Before committing to the issuance of a ROA object, the
> >   signer software should confirm the ipAddrBlocks in the To-Be-Signed
> >   eContent are fully contained by the RFC 3779 extensions listed on the
> >   End-Entity certificate used to generate the signature. 
> > """
> > 
> > In other words, a signing pipeline would help the operator by performing
> > RFC 6482 Section 4 validation *before* constructing the ROA, to prevent
> > constructing ROAs the Repository operator would consider invalid.
> 
> All RPKI CA implementations that I know of already take care to issue
> objects which do not overclaim. The problem is that a delegated CA may
> not find out that a parent has shrunk their resources until whenever
> it happens to send them a "Resource Class List Request" as defined in
> RFC 6492.
> 
> It would be much nicer practice if parent CAs can hold off shrinking
> resources until a child has had a chance to clean up. I will suggest
> some text to the ROV timing draft.. not sure that this belongs there,
> but it may be a start.

The trouble is that by the time the client issues a "Resource Class List
Query", the resources may already have been shrunken and 'its too late'
for the child CA.

Frequently polling the superior CA can help reduce the time window in
which the overclaiming exists, but ultimately I think the default
validation algorithm should be changed to avoid this brittleness.

I hope this group can jointly work on https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-validation-update/

Kind regards,

Job