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

From: Job Snijders <[email-masked]>
Date: Sat, 26 Dec 2020 17:50:49 +0000

Dear group,

Reading draft-michaelson-rpki-rta-02 while writing some work-in-progress
code, I have some suggestions that hopefully improve the ease of use
of RTAs. WIP: http://sobornost.net/~job/rpki-client-rta.patch.txt

While it is useful property of RTAs they can be exchanged via email or
webforms (aka 'private B2B'), I also envision use cases where RTA
objects are best distributed through a publication protocol (public INR
holder statements). I forsee increased interoperability if the document
specifies some constraints on how to publish RTAs via RSYNC/RRDP, if the
Resource Holder chooses to use that path. Some suggestions for text are
included below.

Of course, from a cryptographic validation and 'permissionless
innovation' point-of-view the 'standalone' use of RTAs (without IANA
actions) is perfectly valid and applicable, however from an
interopability point-of-view I would encourage the group to also go
through the motions on describing how to publicly publish RTAs, and thus
target Standards Track.

Kind regards,

Job

---------------------

OLD:
    Intended status: Experimental
NEW:
    Intended status: Standards Track

---------------------

Section 8
OLD:
   An RTA and its associated EE certificates MAY appear on an RPKI
   Manifest and MAY be published in a repository.

NEW:
   An RTA and its associated EE certificates MAY appear on an RPKI
   Manifest and MAY be published in a repository. If an RTA appears
   on an RPKI Manifest, the RTA's file extension MUST be '.rta'.

----------------------

OLD:
    Section 9
    IANA is entirely off the hook on this one.

NEW:
    Section 9.1 OID
    The IANA is requested to reference the '1.2.840.113549.1.9.16.1.36'
    OID as Resource Tagged Attestations in the RPKI Signed Objects
    registry created by [RFC6488].

    Section 9.2 File Extension
    IANA is requested to an item for the Ghostbusters Record file
    extension to the "RPKI Repository Name Scheme" created by [RFC6481]
    as follows: '.rta', 'Resource Tagged Attestation', ref: [draft-michaelson-rpki-rta]

    Section 9.3 Media Type
    The IANA is requested to register the media type application/rpki-rta as follows:

    Type name: application
    Subtype name: rpki-resourcetaggedattestations
    Required parameters: None
    Optional parameters: None
    Encoding considerations: binary
    Security considerations: Carries an Resource Tagged Attestation [draft-michaelson-rpki-rta]
    Applications that use this media type: RPKI users.
    Additional information:
     Content: This media type is a signed object, as defined
         in [draft-michaelson-rpki-rta], which contains an arbitary
         canonicalized payload as defined above in this document.
     Magic number(s): None
     File extension(s): .rta
    Person & email address to contact for further information:
     George Michaelson <[email-masked]>
    Intended usage: COMMON
    Restrictions on usage: None
    Author: George Michaelson <[email-masked]>
    Change controller: George Michaelson <[email-masked]>
--------------------------

---

From: Claudio Jeker <[email-masked]>
Date: Tue, 29 Dec 2020 11:14:12 +0100

> of RTAs. WIP: http://sobornost.net/~job/rpki-client-rta.patch.txt

I checked your diff and the draft. I think one thing in the draft. There
is a big issue with the fact that RTA can be cross signed by multiple
certs. No other resource in RPKI does that and it causes some issues with
the validation process. Until now each CA repo could be checked
independently once ready but now RTA files suddenly have interdependencies
that need special attention. I would like to know why this complication is
needed for RTA - what is the actual use case where multiple signers are
necessary. I currently don't see why this is required (especially since
the resources (ASnum and IP blocks) need to be allowed by all those CA
certs.

Your diff needs some work to actually do the full validation. We should
not punt this off to 3rd party. Also in rta_parse() the calloc uses a
wrong sizeof() rta instead of roa (or better just use sizeof(*p.res)).

RFCs like this need some demo resources to play with.
-- 
:wq Claudio

---

From: Job Snijders <[email-masked]>
Date: Tue, 29 Dec 2020 12:10:14 +0000

Dear group,

On Tue, Dec 29, 2020 at 11:14:12AM +0100, Claudio Jeker wrote:
> There is a big issue with the fact that RTA can be cross signed by
> multiple certs. No other resource in RPKI does that and it causes some
> issues with the validation process. Until now each CA repo could be
> checked independently once ready but now RTA files suddenly have
> interdependencies that need special attention. I would like to know
> why this complication is needed for RTA - what is the actual use case
> where multiple signers are necessary. I currently don't see why this
> is required (especially since the resources (ASnum and IP blocks) need
> to be allowed by all those CA certs.

I agree. Removing subjectKeyIdentifers greatly simplifies the RTA
concept without compromising its application and utility for the use
cases I'd like to deploy. 

With the following new formal definition in mind:

     ResourceTaggedAttestation ::= SEQUENCE {
         version  [0]          INTEGER DEFAULT 0,
         resources             ResourceBlock,
         digestAlgorithm       AlgorithmIdentifer,
         messageDigest         OCTET STRING }

Having the 'resources' listed in the payload (and of course require
those to match what was delegated to the issuing entity, just like is
done with ROAs) makes sense to me, because this way the Relying Party
can understand which of many subordinate resources attested.

For example in the use case I envision for PeeringDB.com:

An entity who have 2 ASNs (199036 and 15562, archived example:
http://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/ZrvTEk3dw4Cs6zD65ee6glPlruQ.cer.html)
wishes to sign-up for PeeringDB.com. They only want to proof to
PeeringDB they own AS 15562 (so AS 199036 is out of scope in this B2B
process).

The PeeringDB.com interface in the sign-up process generates a file with
some random contents, hashes this random data, and then expects the
Resource Holding entity to put the message digest in a RTA. Also they
expect at least resource 'AS 15562' in the 'resources' field. The
operational benefit is that looking at just the validated RTA payload
one can figure out which resource created the digest.

INR ownership verification process:

  Entity holding resources       <->                    PeeringDB.com
         15562, 199036            |

  ---> Express desire to prove ownership for 15562 -->

                                  | Generate file with some random data
                                  | Generate message digest X for the file
                                  | Store digest X as part of onboarding attempt 

      <--- Request INR holder to create RTA with message digest X <---

  Generate RTA with at least      |
  15562 as resource, and digest X |
  in RTA payload                  |

  ---> send the RTA file via email or webform to PeeringDB --->

                                  | Validate RTA, pull out payload.
                                  | Compare whether the digest in the
                                  | RTA payload matches digest X
                                  | stored as part of the onboarding
                                  | attempt

>From a validation perspective, the above process to me seems sufficient
(and state of the art!) for BYOIP / BYOAS purposes. Even if digest X is
intercepted, the onboarding process is not compromised (assuming the
Trust Anchors are not compromised).

Of note should be that the attested file itself is not even exchanged
between the two parties, merely indicating which digest is expected, and
seeing this partciular digest in a valid current RTA is the attestation.

The advantage of using a message Digest as 'nonce' is that both the use
case of just proving ownership vs attesting digital objects (files). So
that part I like a lot, RTA can be used to both form relations and
attest file contents.

Just like ROAs, Ghost Buster Records, or Manifests *payloads* don't have
a set of additional subjectKeyIdentifers referencing to things in the
outer enveloppe, I think RTAs might be better off without them.

Look forward to feedback from others.

> RFCs like this need some demo resources to play with.

Yes.

Kind regards,

Job

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Dec 2020 07:58:29 -0500

Claudio & Job,

RFC 6488 (2.1.6.2) requires use of the SKI in the sid for all "signed 
objects" in the RPKI.

Is the proposal to not use an SKI in the RTA format compatible with this?

Steve

---

From: Claudio Jeker <[email-masked]>
Date: Tue, 29 Dec 2020 16:16:39 +0100

> Is the proposal to not use an SKI in the RTA format compatible with this?

No that is not what I was after.  The usage of SKI as per RFC 6488
(2.1.6.2) is absolutly fine.  My problem with the RTA draft are these
points of the draft (section 3):

   The differences between this RTA profile and the profile specified by
   the RPKI Digitally Signed Object template are as follows:

   o  Section 2.1 of [RFC6488] specifies a single SignerInfo object.  An
      RTA MAY contain more than one SignerInfo object.

   o  Section 2.1.4, and Section 3 of [RFC6488] specify that the
      certificates field contains a single EE certificate.  The
      certificates field of an RTA contains precisely the same number of
      EE certificates as there are SignerInfo objects in the RTA, where
      each EE certificate is needed to validate the signature in each
      SignerInfo.  In addition, the certificates field MAY contain a
      collection of CA certificates that would allow a RP to validate
      the EE certificates.

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.

-- 
:wq Claudio

---

From: Job Snijders <[email-masked]>
Date: Tue, 29 Dec 2020 15:57:07 +0000

> there are more EE certs involved in the validation process.

And even worse, the complexity doesn't appear to provide any benefits:
as can be seen from my example [1], with a reduced RTA eContent profile
the BYOIP / BYOAS use case doesn't require a set of SKIs in the
eContent. If a signer wants to create a RTA for some multi-signer x509
pem encoded file (or their vacation photos), they are free to do so,
what the hash in the RTA eContent represents is out of scope.

I believe a RTA should conceptually be very similar to a single RFC 6486
'FileAndHash', except instead of associating the hash with a IA5String
'file', the hash is associated with one or more Resources delegated to
the Resource holder. Optionally, the hash is associated with an arbitary
digital object outside the RPKI, onlookers won't know if the hash in the
RTA econtent is the message itself or a digest of another digtal object.
A cool property!

Further more (just like in manifests) we can encourage the use of
one-time-use EE certificates. The CA MAY choose to sign only one RTA
with each generated private key, and generate a new key pair for each
new version of the RTA. After generating the RTA the keypair can be
destroyed.

The draft-michaelson-rpki-rta-02 itself describes the presence of these
additional certificates as a 'burden' (section 10):

    """
    RTA objects themselves may appear in repositories, and are
    constrained in size to the ASN.1 encoded burden of the set of
    certificates which are sufficient to describe the RFC3779 resources
    associated with the signatures.
    """

So, why not just remove it? :)

It is possible the RTA authors forsee use cases where the 'multiple
signatures' offers irreplaceable value, I'm not sure.

If this is the case, perhaps a second effort can be spun up: 'A
Simplified RTA Profile'. In this separate second effort a lot of code
can be re-used from the original RTA implementation, making sure no
coding efforts went to waste.

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/sidrops/WCDklq3lOR0LX2ZZkziMlxyWTaU/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 29 Dec 2020 11:14:57 -0500

> there are more EE certs involved in the validation process.
thanks for the clarification.

Your characterization of the added complexity and validation failure 
possibilities is worrisome, given the trouble RPs have had just trying 
to deal with the comparatively simple RPKI signed object validation process.

Steve

---

From: Ben Maddison <[email-masked]>
Date: Wed, 30 Dec 2020 16:48:36 +0200

On 12/29, Job Snijders wrote:
> <snip/>

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