Re: [Sidrops] feedback on draft-michaelson-rpki-rta

Dear all,

Apologies for top-posting, but I wanted to send a readable response highlighting the motivations for the RTA draft and the implementation experience so-far by the co-authors of this draft.

- Use-cases

Please bear in mind that this document is specifically intended as a generic profile, without constraining use cases. This is why it includes the following flexibility:
 - multiple signatures
 - publish in the RPKI, or not
 - option to include the full validation path CAs and CRLS in the CMS
   (think TLS, where validation does not require the assembly of a local cache of signed objects)

The use case is intentionally _not_ limited to secure routing and publishing in the RPKI may not be necessary in envisaged cases.

- Publishing in the RPKI

If the RTA is to be published in the RPKI then indeed the filename extension for the detached signature '.rta' as suggest by Job makes sense. However, in many cases there will be no need to publish these RTA files in the global RPKI. The RTA is in essence a detached signature, and as such they are meaningless if an RP does not know which file they were supposed to sign. The file (or object) which has been signed with a detached signature has no role in a CA’s publication point of signed objects and SHOULD NOT (MUST NOT?) be published in a CA’s publication point.

- Need for multiple signatures

One case here is that an organisation which operates under multiple parents, e.g. two RIRs or an RIR and an NIR, will receive resources on different CA certificates. Similarly organisations under a single RIR may receive multiple certificates if they hold resources transferred from another region, or if they hold so-called legacy resources where another RIR is the majority holder in the IANA registry. Yet, these organisations may wish to make statements about a set of resources that crosses these boundaries. 

There can also be cases where different organisations want to make a joint statement about shared resources. We do not know what case that might be, but as said above - in this phase the profile allows for arbitrary use cases.

- Multi-signing vs multiple single-signing

It is true that requiring single signing for RTAs simplifies the specification. And for some use cases where multiple signatures would be required - multiple single signed RTAs would do fine.

However, with multi-signing relying parties can be sure they have seen the complete set of resources, and expected signatures based on a single file. There is no guessing for the RP as to whether they have seen everything relevant.

Question is of course whether this justifies the additional complexity.

- Multi-sign: Complexity for CA

Having implemented this in Krill I believe that the complexity is not that bad. Essentially this boils down to letting CAs generate keypairs for the EE certificates and agree on a set of resources. Note that the SET of SKIs of these EE certificates and the agreed resource set are part of the signed content. Then one CA can be the first to add their EE certificate containing its resources and sign with the associated private key, and then the next CA (which may be another CA cert held by the same organisation) can add their signature.

For use cases where only a single signature is needed the CA can of course just sign things without the need to synchronise with other parties.

- Multi-sign: Complexity for RPs

(note, I will use an informal description here)

For single signed the RP needs to verify that all resources on the RTA are contained by the EE certificate, which is validly signed all the way back up to a known TA. The RTA MAY include CAs and CRLs needed for this verification. If they are, and if the CRLs are not stale, they will be used for validation. If they are not present, stale or invalid, then the RP can look at the public RPKI and find CA certificates and CRLs there.

For multi signed the process is not changed much. But rather than doing this once, the RP will need to do this N times *and* it will need to verify that the union of resources in the EE certificates used for signing include the described resources.

If N == 1 then this does not increase the complexity. If N > 1 then there may be some fragility, because any of the paths can fail, but it is reasonable to state that if multiple signatures are required then it is a requirement that the RTA MUST be considered invalid if the validation of any signature or EE certificate fails.

Tim

> On 30 Dec 2020, at 15:48, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org> wrote:
> 
> On 12/29, Job Snijders wrote:
>> On Tue, Dec 29, 2020 at 04:16:39PM +0100, Claudio Jeker wrote:
>>> Up until now all objects only had a single EE cert and a single SID and
>>> all the linking done with the SKI was a 1-to-1 mapping resulting in a
>>> simple tree structure with the trust anchor as root.
>>> This draft allows for multiple EE certs and so multiple paths up to the
>>> trust anchors. This makes handling RTA a lot more complex than any other
>>> object under RPKI. It also results in a lot more failure conditions since
>>> there are more EE certs involved in the validation process.
>> 
>> <snip/>
>> 
>> It is possible the RTA authors forsee use cases where the 'multiple
>> signatures' offers irreplaceable value, I'm not sure.
> 
> FWIW, all the use cases that I have in mind for RTA need only a single
> signer.
> I have been trying to think of some creative uses that can't be solved
> by separate objects, and I can't think of any.
> 
> Thus, if this change can speed up implementation then I'm all for it.
> 
> Cheers,
> 
> Ben
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops