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
- [Sidrops] feedback on draft-michaelson-rpki-rta Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Claudio Jeker
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Claudio Jeker
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Ben Maddison
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Tim Bruijnzeels
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Korsback, Fredrik
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Tim Bruijnzeels
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Stephen Kent
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… George Michaelson
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Ben Maddison
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Martin Hoffmann
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… George Michaelson
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Job Snijders
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Martin Hoffmann
- Re: [Sidrops] feedback on draft-michaelson-rpki-r… Di Ma