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

Job Snijders <job@sobornost.net> Tue, 29 December 2020 12:10 UTC

Return-Path: <job@sobornost.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597A63A138A for <sidrops@ietfa.amsl.com>; Tue, 29 Dec 2020 04:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUfarhQIW4nv for <sidrops@ietfa.amsl.com>; Tue, 29 Dec 2020 04:10:23 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7713A1386 for <sidrops@ietf.org>; Tue, 29 Dec 2020 04:10:22 -0800 (PST)
Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id ACB5D60199 for <sidrops@ietf.org>; Tue, 29 Dec 2020 12:10:19 +0000 (UTC)
Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id cbad3371; Tue, 29 Dec 2020 12:10:15 +0000 (UTC)
Date: Tue, 29 Dec 2020 12:10:14 +0000
From: Job Snijders <job@sobornost.net>
To: sidrops@ietf.org
Message-ID: <X+scpsd6kDQ72nLa@bench.sobornost.net>
References: <X+d3+e5Rj/Q7Dchv@bench.sobornost.net> <20201229101412.GA56136@diehard.n-r-g.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201229101412.GA56136@diehard.n-r-g.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/WCDklq3lOR0LX2ZZkziMlxyWTaU>
Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Dec 2020 12:10:26 -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