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

Tim Bruijnzeels <tim@nlnetlabs.nl> Mon, 11 January 2021 15:28 UTC

Return-Path: <tim@nlnetlabs.nl>
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 A800B3A0EF9 for <sidrops@ietfa.amsl.com>; Mon, 11 Jan 2021 07:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 k5NbsiD52b_L for <sidrops@ietfa.amsl.com>; Mon, 11 Jan 2021 07:28:42 -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 1238A3A0EF3 for <sidrops@ietf.org>; Mon, 11 Jan 2021 07:28:41 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (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 20F5F60118; Mon, 11 Jan 2021 15:28:40 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1610378919; bh=vpGQlRAm+dsslQDAYtirXEO7sEhApbGaSzVZMLI6zrg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=oOf8pXEEqVWja5Q6mfNreO2oVeFLoqcgjM7zqNqhKelsylxZqrAReQUK/X0zYu3wq RWdBShIT2qg3hR423J+UFlbxIxEj2Jdk1dx9mekpWYUwHmXpylyDbcdtFKvXBDcuS2 Ln8VZtQ5teJx7wdmJtrmXclAnf/NzAMrdYEvBR5LG0B+LUDKtaK/THAejSQM+UCJc6 Z1LwKfzL47aCbXII4cQQsfgVZSy+k5BL4EvgyFKWd5z+ZMcNFvldcDO4uhYsWkpS6t ScwawtgFPHn2qmPVWVnkAtL/z3NzORGKs8JiFsGMu1cQHk9Or3W3raLWRCi6+mnfFE GqsAnGKP+PYmg==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <8D48337E-A7A0-4C81-973D-0160BE5C6A2B@amazon.com>
Date: Mon, 11 Jan 2021 16:28:37 +0100
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0F6DF16-FBE5-4010-B53A-1B9805BD9056@nlnetlabs.nl>
References: <X+d3+e5Rj/Q7Dchv@bench.sobornost.net> <20201229101412.GA56136@diehard.n-r-g.com> <X+scpsd6kDQ72nLa@bench.sobornost.net> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <X+tR06kF3aPZ4+18@bench.sobornost.net> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <8D48337E-A7A0-4C81-973D-0160BE5C6A2B@amazon.com>
To: "Korsback, Fredrik" <fkback@amazon.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/FsHwHjAEHj3kx-Hvm7H6xEzAERs>
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: Mon, 11 Jan 2021 15:28:45 -0000

Hi Fredrik, group,

There is a trade-off in complexity vs flexibility. So I think we need to have a discussion about quantifying both sides of the equation.

On 11 Jan 2021, at 14:39, Korsback, Fredrik <fkback@amazon.com> wrote:
> 
> Hi.
> 
> So one thing I'm failing to see is the motivation why we step away from the fairly simple "stay within a single TA-cone" model we have in "regular" RPKI.

Multi-signing as specified can be under the same TA, or different TAs.

For most organisations the use case would be that they have multiple certificates under a single parent. While some organisations would have certificates under multiple parents, potentially under different TAs.

> Even if implementing a Multi-signatory support seems simple enough for your implementations, we do not know the full extent of which software is out in the wild that may or may not need full refactors to handle this.

Sure, I am trying to share our experience. I am quite happy to listen to other points of view, but this might help to quantify just how much more complicated this really is.

I suspect that the biggest challenge to RP software here is the notion of bottom-up validation of an RTA file found out-of-band. And we argued that the added challenge of validating multiple EE certificates in that RTA file, verifying that they combined contain all resources in the RTA and they are all present, is not that much harder.

> You bring up "However, with multi-signing relying parties can be sure they have seen the complete set of resources, and expected signatures based on a single file. There is no guessing for the RP as to whether they have seen everything relevant." Wouldn’t this also go the opposite way as well? If a TA goes down and/or is not included in your set of TAs, the multi-signed object goes out? Increasing the blast-radius. With Multiple single-signing this blast radius should lessen. 
> 
> Our usecase is fairly obvious on what we would like to use RTA for (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html#byoip-certificate) since we already have a poor-mans-version of it implemented and used today. Getting simple RTA objects would make our BYOIP-process a lot simpler, make it go faster and reduce the amount of humans involved.

It looks like your use case expects a single prefix or range to be signed. In that case single signed RTA will suffice.

> I can't see any outcome where multi-signing makes sense over multiple single-signing

If your process would accept a set of different resources, then multi-sign could help the end-user experience. Speaking for Krill we intentionally let the operator focus on their intent, and not the 'how'. I.e. you can specify a prefix and ASN and then Krill will figure out under which CA certificate (if you have multiple) a ROA will be issued. Similarly a user could declare intent to create an RTA for resources spanning CA certificates, and the software would just deal with it. And they would just get a single RTA file to upload to your system, rather than -potentially- multiple. This can simplify the steps for the user.

> and keeping recent outages, slow software-updates, and the fairly slow adoption of RPKI in mind it seems that "keep it simple" is going to help with these things. At least more than what this multi-signing paradigm can give us.

The trade-off is the complexity in server and RP software vs flexibility and usability for operators using the software.

I understand that there is a resistance against complexity, I share this aversion. I myself was skeptical until I started coding. It's just that based on my implementation experience so-far this complexity is not that bad and it allows for flexibility in use cases.

The fragility in practice depends on the use case. If your challenge is for single prefixes or ranges then they will in essence by single signed - even if the 1 EE is in a set of 1(*). So, if you only require single prefix then you can just not give the option for sets.

For resource *sets* things depend: if you want to do a one-off validation of an RTA then this fragility is limited, if you want to be able to check at any time whether the RTA is still valid then the outcome is still similar to multiple single-signed: in that case you would have to recheck all RTAs individually and conclude that things are no longer valid if there is an issue with any one of them. So rejecting the multi-signed RTA would be a feature in this case.

Tim

(*): Theoretically a CA could hold adjacent, or overlapping, resources in multiple CA certificates. But in practice this would be extremely unlikely.


> 
> Happy to hear more comments or some tribal knowledge I just don’t understand in this design choice though. 
> 
> --
> Fredrik Korsbäck
> AWS 
> 
> On 2021-01-11, 10:54, "Sidrops on behalf of Tim Bruijnzeels" <sidrops-bounces@ietf.org on behalf of tim@nlnetlabs.nl> wrote:
> 
>    Dear all,
> 
>    Apologies for top-posting, but I wanted to send a readable response highlighting the motivations for the RTA draft and the implementation experience so-far by the co-authors of this draft.
> 
> 
>    - Use-cases
> 
>    Please bear in mind that this document is specifically intended as a generic profile, without constraining use cases. This is why it includes the following flexibility:
>     - multiple signatures
>     - publish in the RPKI, or not
>     - option to include the full validation path CAs and CRLS in the CMS
>       (think TLS, where validation does not require the assembly of a local cache of signed objects)
> 
>    The use case is intentionally _not_ limited to secure routing and publishing in the RPKI may not be necessary in envisaged cases.
> 
> 
>    - Publishing in the RPKI
> 
>    If the RTA is to be published in the RPKI then indeed the filename extension for the detached signature '.rta' as suggest by Job makes sense. However, in many cases there will be no need to publish these RTA files in the global RPKI. The RTA is in essence a detached signature, and as such they are meaningless if an RP does not know which file they were supposed to sign. The file (or object) which has been signed with a detached signature has no role in a CA’s publication point of signed objects and SHOULD NOT (MUST NOT?) be published in a CA’s publication point.
> 
> 
>    - Need for multiple signatures
> 
>    One case here is that an organisation which operates under multiple parents, e.g. two RIRs or an RIR and an NIR, will receive resources on different CA certificates. Similarly organisations under a single RIR may receive multiple certificates if they hold resources transferred from another region, or if they hold so-called legacy resources where another RIR is the majority holder in the IANA registry. Yet, these organisations may wish to make statements about a set of resources that crosses these boundaries.
> 
>    There can also be cases where different organisations want to make a joint statement about shared resources. We do not know what case that might be, but as said above - in this phase the profile allows for arbitrary use cases.
> 
> 
>    - Multi-signing vs multiple single-signing
> 
>    It is true that requiring single signing for RTAs simplifies the specification. And for some use cases where multiple signatures would be required - multiple single signed RTAs would do fine.
> 
>    However, with multi-signing relying parties can be sure they have seen the complete set of resources, and expected signatures based on a single file. There is no guessing for the RP as to whether they have seen everything relevant.
> 
>    Question is of course whether this justifies the additional complexity.
> 
> 
>    - Multi-sign: Complexity for CA
> 
>    Having implemented this in Krill I believe that the complexity is not that bad. Essentially this boils down to letting CAs generate keypairs for the EE certificates and agree on a set of resources. Note that the SET of SKIs of these EE certificates and the agreed resource set are part of the signed content. Then one CA can be the first to add their EE certificate containing its resources and sign with the associated private key, and then the next CA (which may be another CA cert held by the same organisation) can add their signature.
> 
>    For use cases where only a single signature is needed the CA can of course just sign things without the need to synchronise with other parties.
> 
>    - Multi-sign: Complexity for RPs
> 
>    (note, I will use an informal description here)
> 
>    For single signed the RP needs to verify that all resources on the RTA are contained by the EE certificate, which is validly signed all the way back up to a known TA. The RTA MAY include CAs and CRLs needed for this verification. If they are, and if the CRLs are not stale, they will be used for validation. If they are not present, stale or invalid, then the RP can look at the public RPKI and find CA certificates and CRLs there.
> 
>    For multi signed the process is not changed much. But rather than doing this once, the RP will need to do this N times *and* it will need to verify that the union of resources in the EE certificates used for signing include the described resources.
> 
>    If N == 1 then this does not increase the complexity. If N > 1 then there may be some fragility, because any of the paths can fail, but it is reasonable to state that if multiple signatures are required then it is a requirement that the RTA MUST be considered invalid if the validation of any signature or EE certificate fails.
> 
> 
>    Tim
> 
> 
>> On 30 Dec 2020, at 15:48, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org> wrote:
>> 
>> On 12/29, Job Snijders wrote:
>>> On Tue, Dec 29, 2020 at 04:16:39PM +0100, Claudio Jeker wrote:
>>>> 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.
>>> 
>>> <snip/>
>>> 
>>> It is possible the RTA authors forsee use cases where the 'multiple
>>> signatures' offers irreplaceable value, I'm not sure.
>> 
>> 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
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
>    _______________________________________________
>    Sidrops mailing list
>    Sidrops@ietf.org
>    https://www.ietf.org/mailman/listinfo/sidrops
>