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

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 11 Jan 2021 10:53:51 +0100

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=[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: "Korsback, Fredrik" <[email-masked]>
Date: Mon, 11 Jan 2021 13:39:33 +0000

Hi.

So one thing I'm failing to see is the motivation why we step away from the fairly simple "stay within a single TA-cone" model we have in "regular" RPKI. Even if implementing a Multi-signatory support seems simple enough for your implementations, we do not know the full extent of which software is out in the wild that may or may not need full refactors to handle this. 

You bring up "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." Wouldn’t this also go the opposite way as well? If a TA goes down and/or is not included in your set of TAs, the multi-signed object goes out? Increasing the blast-radius. With Multiple single-signing this blast radius should lessen. 

Our usecase is fairly obvious on what we would like to use RTA for (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html#byoip-certificate) since we already have a poor-mans-version of it implemented and used today. Getting simple RTA objects would make our BYOIP-process a lot simpler, make it go faster and reduce the amount of humans involved. I can't see any outcome where multi-signing makes sense over multiple single-signing and keeping recent outages, slow software-updates, and the fairly slow adoption of RPKI in mind it seems that "keep it simple" is going to help with these things. At least more than what this multi-signing paradigm can give us. 

Happy to hear more comments or some tribal knowledge I just don’t understand in this design choice though. 

--
Fredrik Korsbäck
AWS 

On 2021-01-11, 10:54, "Sidrops on behalf of Tim Bruijnzeels" <[email-masked] on behalf of [email-masked]> wrote:

    Dear all,

    - Use-cases

    - Publishing in the RPKI

    Tim

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 11 Jan 2021 16:28:37 +0100

Hi Fredrik, group,

There is a trade-off in complexity vs flexibility. So I think we need to have a discussion about quantifying both sides of the equation.

On 11 Jan 2021, at 14:39, Korsback, Fredrik <[email-masked]> wrote:
> 
> Hi.
> 
> So one thing I'm failing to see is the motivation why we step away from the fairly simple "stay within a single TA-cone" model we have in "regular" RPKI.

Multi-signing as specified can be under the same TA, or different TAs.

For most organisations the use case would be that they have multiple certificates under a single parent. While some organisations would have certificates under multiple parents, potentially under different TAs.

> Even if implementing a Multi-signatory support seems simple enough for your implementations, we do not know the full extent of which software is out in the wild that may or may not need full refactors to handle this.

Sure, I am trying to share our experience. I am quite happy to listen to other points of view, but this might help to quantify just how much more complicated this really is.

I suspect that the biggest challenge to RP software here is the notion of bottom-up validation of an RTA file found out-of-band. And we argued that the added challenge of validating multiple EE certificates in that RTA file, verifying that they combined contain all resources in the RTA and they are all present, is not that much harder.

> Our usecase is fairly obvious on what we would like to use RTA for (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html#byoip-certificate) since we already have a poor-mans-version of it implemented and used today. Getting simple RTA objects would make our BYOIP-process a lot simpler, make it go faster and reduce the amount of humans involved.

It looks like your use case expects a single prefix or range to be signed. In that case single signed RTA will suffice.

> I can't see any outcome where multi-signing makes sense over multiple single-signing

If your process would accept a set of different resources, then multi-sign could help the end-user experience. Speaking for Krill we intentionally let the operator focus on their intent, and not the 'how'. I.e. you can specify a prefix and ASN and then Krill will figure out under which CA certificate (if you have multiple) a ROA will be issued. Similarly a user could declare intent to create an RTA for resources spanning CA certificates, and the software would just deal with it. And they would just get a single RTA file to upload to your system, rather than -potentially- multiple. This can simplify the steps for the user.

> and keeping recent outages, slow software-updates, and the fairly slow adoption of RPKI in mind it seems that "keep it simple" is going to help with these things. At least more than what this multi-signing paradigm can give us.

The trade-off is the complexity in server and RP software vs flexibility and usability for operators using the software.

I understand that there is a resistance against complexity, I share this aversion. I myself was skeptical until I started coding. It's just that based on my implementation experience so-far this complexity is not that bad and it allows for flexibility in use cases.

The fragility in practice depends on the use case. If your challenge is for single prefixes or ranges then they will in essence by single signed - even if the 1 EE is in a set of 1(*). So, if you only require single prefix then you can just not give the option for sets.

For resource *sets* things depend: if you want to do a one-off validation of an RTA then this fragility is limited, if you want to be able to check at any time whether the RTA is still valid then the outcome is still similar to multiple single-signed: in that case you would have to recheck all RTAs individually and conclude that things are no longer valid if there is an issue with any one of them. So rejecting the multi-signed RTA would be a feature in this case.

Tim

(*): Theoretically a CA could hold adjacent, or overlapping, resources in multiple CA certificates. But in practice this would be extremely unlikely.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Jan 2021 10:31:21 -0500

Tim,

You said:

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

The CP (RFC 6484) imposes constraints on the set of uses for certs 
issued under the RPKI (and thus containing the designated policy OID). 
As noted in the introduction, RPKI certs are "designed exclusively for 
use in support of validation of claims related to current INR holdings." 
Using ANY cert containing the OID defined in the CP for ageneric set of 
cases violates the CP. Thus it is inappropriate to publish a spec that 
uses certs issued under the RPKI (whether published in the repository 
system or not) for applicatons inconsistent with the CP.

Steve

---

From: George Michaelson <[email-masked]>
Date: Tue, 12 Jan 2021 08:34:13 +1000

The use case is to tag other information with INR.

The note Tim made was that the intent of RTA is not limited to secure
routing, not that it is intended to be used for signing without
reference to INR.

-G

On Tue, Jan 12, 2021 at 1:31 AM Stephen Kent
<stkent=[email-masked]> wrote:
> The CP (RFC 6484) imposes constraints on the set of uses for certs issued under the RPKI (and thus containing the designated policy OID). As noted in the introduction, RPKI certs are "designed exclusively for use in support of validation of claims related to current INR holdings." Using ANY cert containing the OID defined in the CP for a generic set of cases violates the CP. Thus it is inappropriate to publish a spec that uses certs issued under the RPKI (whether published in the repository system or not) for applicatons inconsistent with the CP.
>
> Steve
>
>

---

From: Ben Maddison <[email-masked]>
Date: Tue, 12 Jan 2021 16:58:00 +0200

Hi Tim, all,

Happy new year... hopefully :-)

> 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 certificate…
This was kinda the point I was making when I said that I couldn't think
of any use-cases for which multiple RTAs wouldn't work:

The above logic works just the same if you instead have N RTAs over the
same signed data, and require that the union of `resources` from each be
the same as the set described in the signed data.

Doing it this way seems to present the advantage of decoupling the
rpki-validation of the CMS blob from the application-specific-validation
of the underlying data.

Every use case for this will require tooling to perform additional
validation of the signed data against the RTA (at least verifying the
digest, probably more), so this doesn't introduce a new step in the
process, it just moves responsibility for it out of the RTA spec.

> 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 req…
It arguably also adds flexibility, in that the consequences of having an
incomplete set can be application-specific. In some cases, a partial set
may be useful, in others it may render all the RTAs useless.

When I started writing this email, I was mostly agnostic other than
insofar as this may speed-up or delay implementation.

Having thought about it, I actually think the multiple RTAs pattern is
better than the multiple signer pattern.

Cheers,

Ben

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 12 Jan 2021 16:50:15 +0100

Ben Maddison wrote:
> 
> This was kinda the point I was making when I said that I couldn't
> think of any use-cases for which multiple RTAs wouldn't work:
> 
> The above logic works just the same if you instead have N RTAs over
> the same signed data, and require that the union of `resources` from
> each be the same as the set described in the signed data.
> 
> rpki-validation of the CMS blob from the
> application-specific-validation of the underlying data.

A drawback of this is, however, that you cannot decide anymore whether
your document is truly "RTA invalid" or if you are just missing some
of the data. Or, turned around, somehow loosing an RTA from the set
makes the underlying data seem invalid even though it isn’t.

This is quite similar to the situation we have in origin validation
where loosing a ROA from the set may make a route invalid.

Forcing all relevant data into a single object avoids this problem and
makes an invalid a definitive invalid.

> process, it just moves responsibility for it out of the RTA spec.

I’m not sure that is a desirable outcome. In its currently proposed
form, RTA processing in its generic, application independent form
handles all of the processing related to resources. You give it an RTA
and a hash and it returns either a set of valid resources or a validation
error. All of the application specific processing can be easily built
around that.

If RTAs are split, the application has to call into this interface
multiple times and then has to decide how to merge the multiple results.
That means each application has to define how to do that and both ends
have to correctly do that.

The work of dealing with resources under multiple parents has to be
done. I think doing it once in a well-defined way is a better approach.

 - Martin

---

From: Job Snijders <[email-masked]>
Date: Tue, 12 Jan 2021 19:17:05 +0000

On Tue, Jan 12, 2021 at 04:58:00PM +0200, Ben Maddison wrote:
> > 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.
> 
> It arguably also adds flexibility, in that the consequences of having
> an incomplete set can be application-specific. In some cases, a
> partial set may be useful, in others it may render all the RTAs
> useless.
> 

1/
We should be cognizant Relying Parties might not have all applicable
Trust Anchors in common with each other. Lacking a single common Trust
Anchors will invalidate the entire multiple-SignerInfo RTA.
Troubleshooting such cases in a multiple-SignerInfo will be harder
compared to each RTA object containing a single SignerInfo (and thus is
bound to a single Trust Anchor).

2/
The complexity of Multiple-SignerInfo in a Multiple-Trust Anchors
context is further compounded when one takes into consideration any
additional variances resulting from different X509 Certificate Policies
(RFC 6487 & RFC 8360) on different validation paths towards a single
multiple-SignerInfo RTA. 

3/
I think SIDROPS needs to take a hard look at whether significant
increases of complexity are a wise move at this phase of global RPKI
deployment. 'Mixing' of Trust Anchor trees at this 'pre-validation
stage' is a big unknown for the working group, it has not been done
before. Contrary to Martin's comment "The work of dealing with resources
under multiple parents has to be done." ... that's just not true,
this is not work that *has* to be done, it is entirely avoidable.

Given how much problems some validator implementers had in 2020 (and
still have!) to just get manifest & CRL basics right, makes me very
skeptical about the group's ability to now suddenly perform at a much
more advanced level.

4/
Last but not least: if we follow a single-SignerInfo model, all the
RIRs/NIRs should be able to fairly easy to implement a web tool for:

    'copy+paste attested object's hash here -> click which resource should sign -> download resulting RTA'.

Implementing single-SignerInfo RTA at the RIR-hosted CA level can
be straight forward, as such hosted services only needs to concern
themselves with a single Trust Anchor (themselves) and there won't be
passing around of RTAs for co-signing. The RIR-hosted portal also
doesn't need to see the actual digital object being attested, just the
hash. I fear multiple-signerinfo RTA would see lack of adoption in that
part of the ecosystem, and "just use krill" is not the answer.

Summary:

* multiple people have indicated immediate use-cases for single SignerInfo
* multiple people have voiced concerns about multiple-signerInfo
* I've expressed a willingness to facilitate a single SignerInfo
  implementation, but I'm not willing to implement or support multiple
  SignerInfo.

I hope the authors reconsider so we can get down to the business of
deploying RTA! :-)

Kind regards,

Job

---

From: George Michaelson <[email-masked]>
Date: Wed, 20 Jan 2021 15:43:16 +1000

On Wed, Jan 13, 2021 at 4:46 AM Job Snijders <[email-masked]> wrote:
> On Tue, Jan 12

I agree. I think there is good convergence to understanding this
drive. It is easy to sell the idea of an RTA with only one EE
certificate signing its contents.

> * multiple people have voiced concerns about multiple-signerInfo

I think it is not clear why we want this. I need to try and be clear about this:

APNIC operates a set of subsidiary CA under our trust anchor which
follow the path of entry of INR into our duty of care. So, for our
members in particular, it is not unusual to want to make assertions
about "all my holdings" which innately demand more than one CA be
brought into play. This is not multiple signing entities, it is one
entity, controlling a set of EE certificates which are neccessary to
make the signing assertion over the list of INR related to the
context.

It is true that when we designed RTA we did design it to encompass
discretely different entities (people) sending a cryptographically
verifiable statement of intent or meaning which bound them together
mutually. So, we still see utility in this, but I understand how
people in routing contexts don't see that right now. But, the thing is
we are not looking to solve only routing-active (BGP) problems in
RPKI: we are looking to provisioning and other contexts, where it
would be logistically hard to have to deal with a number of discrete
parts to be assembled to make the assertion, compared to being able to
use one: An example here is the JSON submission path in BYOIP, which
really expects a singleton to be passed in.  in APNIC, neccessarily,
this is a set of EE signing.

>   implementation, but I'm not willing to implement or support multiple

Job I think this is an unhelpful assertion. Of course you own your own
code, but choosing to ignore work which is well formed, ASN1 and is
capable of being multiple signing EE certificates is I think wrong.

We have two valid inter-operable multiple signing implementations already.

If you could reconsider, and at the very least demonstate that you can
manage a singly signed instance, but inside the wrapper in ASN.1 which
is innately capable of being multiply signed, I think it is very
likely this will permit well formed, singly signed things to become
normal inside this form of CMS which can be used by other people to
say things which demand multiple signings.

I can easily conceive of things in ASPA  or customer-cone which could
benefit from tying somebody else's AS and the IP, which innately
demand both partys signal intent. You just said you are not willing to
think about implementing improvements to routing security which could
leverage that.

> I hope the authors reconsider so we can get down to the business of

I very much hope you re-consider, and understand why we have chosen to
retain multiple signing capability in the CMS wrapper: We see a lot of
problems with demanding asset holders go into multiple, discrete,
unrelated assertions to declare intent over the whole of their
holdings, and we think this is a situation which is very likely to
become more common, especially as people become bound into inheritance
of INR which lie in different regions, but one ASNs assertion of
routing.

Russ Housely has been kind enough to act as an ASN.1 "expert" and
reviewed our logic, and made some changes in the formalisms of how we
declare the ASN.1 for the CMS, but without changing the on-the-wire
encoding. I have included this in the 00 revision, posted to the WG
under the WG name.

cheers

-George

---

From: Job Snijders <[email-masked]>
Date: Wed, 20 Jan 2021 10:21:49 +0100

Dear George,

> We have two valid inter-operable multiple signing implementations

I hope you will document these efforts and share with the group an
implementation report outlining the interopability characteristics.

I've requested both signing implementers for validatable samples of a
singleton-SignerInfo and a multiple-SignerInfo RTA. So far I received
only one singleton-SignerInfo RTA (thank you Tim!).

Can you or anyone else share with me a multiple-SignerInfo RTA
validatable through a single common Trust Anchor such as the APNIC TA?

Can you or anyone else share with me a multiple-SignerInfo RTA with
signatures from multiple CAs under multiple common TAs (RIPE + APNIC)?

Kind regards,

Job