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

George Michaelson <ggm@algebras.org> Wed, 20 January 2021 05:43 UTC

Return-Path: <ggm@algebras.org>
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 D2C9A3A0D50 for <sidrops@ietfa.amsl.com>; Tue, 19 Jan 2021 21:43:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, 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=algebras-org.20150623.gappssmtp.com
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 nZmuYQTUXumN for <sidrops@ietfa.amsl.com>; Tue, 19 Jan 2021 21:43:31 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058B13A0D64 for <sidrops@ietf.org>; Tue, 19 Jan 2021 21:43:29 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id v67so32538974lfa.0 for <sidrops@ietf.org>; Tue, 19 Jan 2021 21:43:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qBF/kKwLCiOG0GqQgo4alL+Lfvt7f6i77igWGB4YTQY=; b=VGkHyXcghkmCCTio7TVOYZaJTC0Z78QwRmbU8QGSuLYIPGp+ZXcLM2L0zoZUitPzS3 jiyBJtdjUWhJU2C1+TVVGY4/6ufREs2du9nwYAnrkvv+hAC+VH5VzNjzaKJrKT7Vb1Bo FyQVA17eg9dWdtAA6JfB0RWjvxLlmYvka7vNsAoKl1lcUhjP/FvSyK0fhQOpUJ8pU7FH YjxkcivrtqVADuxCA9RJwJo1912CE/8H2kgALW9JmQh3LMOJLVgpLIpZtONnY5Gc5Isf arFOWnouJ3LDNPAuyojiaaWpEWDdemqdn8Lp11APRCT1580icONGaYjFtKgjCkj9YBJe NbKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qBF/kKwLCiOG0GqQgo4alL+Lfvt7f6i77igWGB4YTQY=; b=jiF/LyPwLJYFp3kybd7tB58tq3QpS1NRuR0sM9YCel0UHzMKpS5MK/qTZT6qcY8aEn ysPiTl37r0O8T6RuH/93xTroFq0Yo2UJGhmDpG4nCxtgvib7natKnXD6eFe1RdbP6vAG FFhsi5BT0QwatVCUQgFNWKYUqYFwMph3Qfa/F/lhfTgXbIJJlVS6AnYaMVYryXBbLcnb TMwRy7kXeC6MLnAD+WNPxBjV3HcPBKTTgb+92KvhE63WmLES8YCcQPLhbp0HQRvRR58M QYCkl4vI4Vrzoi7RY88BLxV87+PSC1+P8hLht77uOGLtR+D7pc/4YMF8PikAQplCrN5z vagg==
X-Gm-Message-State: AOAM531nT1YZGFiVxK9HmJg3sskWrCu98/PjRG3Wew2tPVtspS/ngqDX eAPKzsz93noYra2Nqq+OVZI1Ur85FqAd6szYUikWkw==
X-Google-Smtp-Source: ABdhPJyRCQ40SDHuvuDA444yskq1tbxArO0qSZBSeZmYOOpua7beYbdo38gmK1waUy2Y7wOQnHYwR3vzOQwWNTuwRUM=
X-Received: by 2002:ac2:4943:: with SMTP id o3mr674335lfi.384.1611121408041; Tue, 19 Jan 2021 21:43:28 -0800 (PST)
MIME-Version: 1.0
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> <20210112145800.nocjbd4millmbx4i@benm-laptop> <X/31sdsc/ZzGDsjf@bench.sobornost.net>
In-Reply-To: <X/31sdsc/ZzGDsjf@bench.sobornost.net>
From: George Michaelson <ggm@algebras.org>
Date: Wed, 20 Jan 2021 15:43:16 +1000
Message-ID: <CAKr6gn3z_N=xGbScwe3xTUxbqWwySwAkncSbm0KKyDZjwVucOA@mail.gmail.com>
To: Job Snijders <job@sobornost.net>
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/RXBqH43bBHXZgvIlT5IkEuWxzYE>
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: Wed, 20 Jan 2021 05:43:35 -0000

On Wed, Jan 13, 2021 at 4:46 AM Job Snijders <job@sobornost.net> wrote:
>
> On Tue, Jan 12
> Summary:
>
> * multiple people have indicated immediate use-cases for single SignerInfo

I agree. I think there is good convergence to understanding this
drive. It is easy to sell the idea of an RTA with only one EE
certificate signing its contents.

> * multiple people have voiced concerns about multiple-signerInfo

I think it is not clear why we want this. I need to try and be clear about this:

APNIC operates a set of subsidiary CA under our trust anchor which
follow the path of entry of INR into our duty of care. So, for our
members in particular, it is not unusual to want to make assertions
about "all my holdings" which innately demand more than one CA be
brought into play. This is not multiple signing entities, it is one
entity, controlling a set of EE certificates which are neccessary to
make the signing assertion over the list of INR related to the
context.

It is true that when we designed RTA we did design it to encompass
discretely different entities (people) sending a cryptographically
verifiable statement of intent or meaning which bound them together
mutually. So, we still see utility in this, but I understand how
people in routing contexts don't see that right now. But, the thing is
we are not looking to solve only routing-active (BGP) problems in
RPKI: we are looking to provisioning and other contexts, where it
would be logistically hard to have to deal with a number of discrete
parts to be assembled to make the assertion, compared to being able to
use one: An example here is the JSON submission path in BYOIP, which
really expects a singleton to be passed in.  in APNIC, neccessarily,
this is a set of EE signing.

> * I've expressed a willingness to facilitate a single SignerInfo
>   implementation, but I'm not willing to implement or support multiple
>   SignerInfo.

Job I think this is an unhelpful assertion. Of course you own your own
code, but choosing to ignore work which is well formed, ASN1 and is
capable of being multiple signing EE certificates is I think wrong.

We have two valid inter-operable multiple signing implementations already.

If you could reconsider, and at the very least demonstate that you can
manage a singly signed instance, but inside the wrapper in ASN.1 which
is innately capable of being multiply signed, I think it is very
likely this will permit well formed, singly signed things to become
normal inside this form of CMS which can be used by other people to
say things which demand multiple signings.

I can easily conceive of things in ASPA  or customer-cone which could
benefit from tying somebody else's AS and the IP, which innately
demand both partys signal intent. You just said you are not willing to
think about implementing improvements to routing security which could
leverage that.

>
> I hope the authors reconsider so we can get down to the business of
> deploying RTA! :-)

I very much hope you re-consider, and understand why we have chosen to
retain multiple signing capability in the CMS wrapper: We see a lot of
problems with demanding asset holders go into multiple, discrete,
unrelated assertions to declare intent over the whole of their
holdings, and we think this is a situation which is very likely to
become more common, especially as people become bound into inheritance
of INR which lie in different regions, but one ASNs assertion of
routing.

Russ Housely has been kind enough to act as an ASN.1 "expert" and
reviewed our logic, and made some changes in the formalisms of how we
declare the ASN.1 for the CMS, but without changing the on-the-wire
encoding. I have included this in the 00 revision, posted to the WG
under the WG name.

cheers

-George