[routing-wg] request for feedback: a RPKI Certificate Transparency project?

> On 10 Sep 2021, at 11:57, Job Snijders <job at fastly.com> wrote:
> 
> On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
>> I think all would agree that transparency is good.
>> 
>> A key difference between RPKI and most other PKIs is that in the RPKI
>> all objects are published in the open for all the see. 
> 
> Small nitpick: all objects are SUPPOSED to be published, in the open,
> for all to see. However it is important to keep in mind we cannot assume
> all objects were published in a way for all to see.
> 
>> As you mentioned your RPKI validator may miss intermediate state
>> changes if it retrieves objects using rsync, but the RRDP protocol
>> supports deltas, see [1].
>> 
>> I believe that transparency can most easily be achieved by ensuring
>> that these deltas are preserved, and that they cannot be modified.
> 
> RRDP is an unauthenticated and unsigned protocol. It is possible for a
> Publication Point to present different RRDP deltas to one RP compared to
> what they present to another RP. Archiving RRDP deltas is interesting,
> but IMHO happens too late in the pipeline for TA/CA audit purposes.
> 
> RRDP is not a replacement for Certificate Transparency, both
> technologies solve different problems.

I did not say that it was.

I just suggested that *in the context of RPKI* RRDP can be used as a basis
to keep track of all historic public changes.

I think we can discuss, preferably in the IETF as well, how multiple
parties can observe changes in RRDP repositories and report them to
an append only historic record. A useful concept also used in CT.
Paranoid (as they should be) RPKI validators would then be able to
verify that the state that they see (notification/snaphot/deltas)
matches what others have seen.

The biggest advantage to an approach like this could also be applied
on top of the existing infrastructure without requiring substantial
changes in the stack.

If you do not trust that the Publication Server (which serves RRDP)
accurately reflects what the RPKI CAs asked to be published then you
indeed have a different problem. CT logs could be one way to approach
this, but I am not convinced yet that this is the only way or the
best way.

Also note that in case of RIPE NCC the CAs and Publication Server are
controlled by the same organisation.

Kind regards,
Tim



> 
> Kind regards,
> 
> Job