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

[Martin Hoffmann <[e-mail]>]

Job Snijders wrote:
> 
> I've consulted with various subject matter experts, and at George's
> request I again reconsidered. Unfortunately I could not arrive at a
> different conclusion about the current RTA proposal, it is too
> complicated for me to support.

There’s a detail I would like to point out: You can only use the
existing software more or less unchanged if you distribute RTAs through
the regular RPKI repository system. I think doing so is a bad idea
for two reasons.

For one, an RTA is an exchange between a very small number of
participants -- typically just two --, but distribution via the RPKI
repository system results in every single relying party having to
downloading the object. That strikes me as rather wasteful. At the very
least relying parties need to download the object and calculate a hash
over them to determine whether the manifest is valid. Every one needs
to do that. Yet only really one or two parties actually care.

Second, distribution through the RPKI repository is actually quite
cumbersome as it involves a kind of break of gauge: You exchange
documents in whatever way you choose (likely some kind of HTTP API) but
then have to stop, fire up an RPKI relying party tool and wait until it
sees the promised object. Because there uncertainties in timing of RPKI
publication, you need to be prepared to wait for quite a bit.

If, conversely, the RTA can be distributed by any other means, i.e., it
is just a file, it can be transferred as part of your document
exchange. Bundle it with your document for automated processing or
upload it manually via a browser. No waiting involved: both parties
know that the RTA has been transmitted.

But if you allow that, you can’t use RFC 6488 signed objects anymore --
or, well, not properly since at the very least you don’t have the a
signedObject SIA rsync URI anymore. (And yes, the current draft glances
over this fact.)

So, if you have to change your code anyway, why not allow it to deal
with a legitimate, existing use case?

In addition to allow multiple signatures, the draft also allows the
signer to include all necessary certificates and CRLs so that for
validation you wouldn’t even need to access the RPKI repository system
at all. Needless to say, doing that requires quite a bit of different
code but, I do believe that this is worth it, as it seriously
streamlines any process that involves validating RTAs as it can now be
done in a library pretty much without keeping state.  

  - Martin