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

[Tim Bruijnzeels <[e-mail]>]

Hi Job, all,

> On 30 Mar 2021, at 12:00, Job Snijders <job=[e-mail]> wrote:
> 
> Hi Tim, working group,
> 
> first things first: I support adoption of this draft.
> 
> On Mon, Mar 29, 2021 at 04:06:56PM +0200, Tim Bruijnzeels wrote:
>> = revocation?
>> 
>>   A large number of experiments for the process of ROA issuance have
>>   been made on our RPKI testbed, it is found that the misconfigurations
>>   during the issuance may cause the ROAs which have been issued to be
>>   revoked.
>> 
>> I don't see how the ROAs would be revoked in this context.
> 
> Perhaps 'revoked' is the wrong word, maybe 'withdrawn' or 'unpublished'?
> 
> I took the third suggestion in 'Section 3' to mean that if the ROA
> issuer does not confirm the End-Entity certificate signing the ROA
> eContent checks that it is allowed to sign the resources listed in the
> eContent, it might end up submitting an invalid object to the
> Repository.
> 
> The Repository deferences any previous ROA with the same filename,
> performs validation on the newly submitted ROA, concludes it is invalid
> (because the resources in the eContent overclaim compared to the
> resources listed as subordinate on the EE cert) and ends up publishing a
> CA Repository without the intended ROA.

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.


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.

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

Tim



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