Re: [Sidrops] adopt draft-ymbk-sidrops-rpki-has-no-identity please

Dear WG,

> On 25 Mar 2021, at 08:26, Martin Hoffmann <martin@nlnetlabs.nl> wrote:
> 
> Randy Bush wrote:
>> 
>> when
>> the monkey uses its CA access credentials to cause the CA to sign some
>> document/object, it is the primary actor trying to fool you into
>> believing it is a rabbit.
> 
> Keep in mind that these statements are not protecting the issuer but
> the receiver. As such it is the receiver’s task to assess what exactly
> they can reasonably deduce from the statement and if it is fit for
> whatever purpose they use it for.
> 
> In other words, if you believe from a bunch of signed carrots that a
> monkey is a rabbit, that’s on you.
> 
> I don’t think a standalone document stating what a signature derived
> from an RPKI CA means (or, rather, as is the case in the draft, does
> not mean) is necessary. Instead, discussing this in the security
> consideration of the document defining the signed statement will
> suffice. Again, it is on the party accepting these signed statements
> to do their due diligence to protect themselves from liability.

Rabbits aside..

I think the crux of the concern is that:

1. Operators who have been given control over an RPKI CA for routing related assertions such as ROAs, are not necessarily trusted by their organisation to make other statements about the internet number resources that their RPKI CA is authoritative over.

2. Statements about resources could also be made by operators of parent CAs.

And indeed the RPKI is not about identity.

On process:
I believe this is understood by the authors of both the RSC and RTA specs, and I agree with Martin that in as far that it is not clear this should be addressed in the Security Considerations of those documents. If the working group prefers to have a separate document that talks about this, so that the Security Considerations sections can refer to this - as Job has done in the RSC -02 draft, then that is also fine with me. I believe that the objective is to have clarity - so whatever works.

On content:
Indeed it should be clear to receivers of RSC/RTA statements that the assertions could be made by anyone with administrative control over an RPKI CA with the listed resources. They should apply their own due diligence to ensure that signatures are not only valid, but also relevant in their context.

So, in some cases RSC/RTA could be entirely irrelevant, or not authoritative - e.g. a network operator with control over an RPKI CA may not be authoritative to say that an IP prefix can be sold. But, going with the "Bring your own IP" example I expect no such issues: for one it's very much routing related, and secondly I believe that there was a proposal that a cloud provider would use RSC in a way similar to two factor: they would (1) require that a ROA exists, without caring *who* created it - and acknowledging that it could even be a mistakenly created ROA, and then (2) require that a known client confirms the assertion by means of a separate signature over a challenge (eg UUID) for those resources, sent to them over a trusted channel.

The RSC and RTA specs are generalized specifications, so therefore their security considerations can only be generalized as well. An alternative could be to have explicit specifications for each use case, then each specification can clearly define their own considerations and applicability. However, I think that there is value in keeping the generalized RSC/RTA specifications as templates. Much like how RFC 6488 is a "Signed Object Template for the Resource Public Key Infrastructure (RPKI)".

Tim

> 
> -- Martin 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops