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

Ben Maddison <benm@workonline.africa> Tue, 12 January 2021 14:58 UTC

Return-Path: <benm@workonline.africa>
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 971F93A1378 for <sidrops@ietfa.amsl.com>; Tue, 12 Jan 2021 06:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=workonline.africa
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 gdmZ-itPCLN2 for <sidrops@ietfa.amsl.com>; Tue, 12 Jan 2021 06:58:15 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2088.outbound.protection.outlook.com [40.107.22.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1003A1379 for <sidrops@ietf.org>; Tue, 12 Jan 2021 06:58:13 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MroUaKUMKkhVH4cgGbSl9Kibs3XOFCyOZjxi2DriHGnRQB1FPAYBmcqFHWSJFuC1K751zNMZ8RM/tqHQyweVYHuIhpNb5MZjSWQK/RkwS8BWyCG5rDu4Vj6daPG2GdPqaJJbiNULF1Yh99wahFGl/0h0MfNQoCc8dSppwBuLKcvsZQ0+fVWs6Y0SpAtgKIb3UjH3b5C4dFqFOGpHj6ooxYi/wzPgkOroiLUgad05jT06HKcsV5p0eR4LuXUQhdmXswQvStoOvDdZbfurwWu2oYjQoEg9k3bbSvAYkelTjrAURaVyUYZd8bocUzRuSLyTm6fJp+PrJO2ofI0pjphA3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YELZFMDUlp853DYWPrAT9bUXPmoxVjXtdJkQVle0Wio=; b=h3xUazrCRcaEzXsU88n/RdQCpLYFnFdhuBgpisAWxBV5C+2vQxGNR9g5E4sUn2zAXGs83HIPbIL6L89i3J5/hc17Jke1DmtNnvJEFuS21fNJ0IFo8NP8PrZH8TRo9/m5CtOi081dqHgRR/R80Gi67y0dNLhs8X7Jghaf176Cn/poOBkfxBC2ClRLDkizruoR66LmvCTYD1Wasvo18ixKaTYUxYyQz5wIxcZOvU6CpB5zcPJMB75QiYp8urAE+LsN16t1s0z5JW3ZRDDExRGnvo9vZTYdsTefoWCqsiZDTqSAvcd0IJloENhWf2qrErfRNzXC9mmtDmsCJzRNhRqVyw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YELZFMDUlp853DYWPrAT9bUXPmoxVjXtdJkQVle0Wio=; b=tOUKw9rOXY4KMMYKRXNOBdcfg3ZSUVV5GOCZN3CCwIv69QEUR7WprDpa3qztg+lgGarU2+v8rjMo1QNL9n/LSzSo/DgMqTEt8PCTfTk1a+Qn5uRipH5gmbs/q1sHbon+94tBXOgOnR2tzN7yN7ncmOi3G5DNEQV9nAUZCLN/HHg=
Authentication-Results: nlnetlabs.nl; dkim=none (message not signed) header.d=none;nlnetlabs.nl; dmarc=none action=none header.from=workonline.africa;
Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24) by DB6P190MB0453.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:32::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.8; Tue, 12 Jan 2021 14:58:08 +0000
Received: from DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::a8b1:5eb6:5886:96c2]) by DB8P190MB0746.EURP190.PROD.OUTLOOK.COM ([fe80::a8b1:5eb6:5886:96c2%3]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 14:58:08 +0000
Date: Tue, 12 Jan 2021 16:58:00 +0200
From: Ben Maddison <benm@workonline.africa>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: SIDR Operations WG <sidrops@ietf.org>, Job Snijders <job@sobornost.net>
Message-ID: <20210112145800.nocjbd4millmbx4i@benm-laptop>
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>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yvqbgsawf3vjytn6"
Content-Disposition: inline
In-Reply-To: <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl>
X-Originating-IP: [165.0.73.66]
X-ClientProxiedBy: CTXP275CA0043.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::31) To DB8P190MB0746.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:12a::24)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (165.0.73.66) by CTXP275CA0043.ZAFP275.PROD.OUTLOOK.COM (2603:1086:100:1::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9 via Frontend Transport; Tue, 12 Jan 2021 14:58:07 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 03c9f096-d0b6-4e2a-fd54-08d8b70a7920
X-MS-TrafficTypeDiagnostic: DB6P190MB0453:
X-Microsoft-Antispam-PRVS: <DB6P190MB0453931469FC53ECB41C338AC0AA0@DB6P190MB0453.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: ppOj2rIn5B/A+od3/1Ke5wzAj4OoUwd7yy3qWo8C6ahl4QTGQFLqlIl42bOdmutCwt2Ly74ksbxvdbDLS2sbIBoxgLsx9ewPS57tvAQaFH39ascSFywTaPO7omF3w9hCLTTNYXB2TLM4Q9bqSb4+9Z4Up3bIKuIDGh8XYKeYxKAxotqFEC2a7gFgmaNU0puiLBgM+cGtJX2KwkRvAmrGjcCld/Y/BZdAtJQQLKycJz3qZ5ZxLpJlLNGG5w00igXbquN6qXoiJg+YrrJOU03WwFAYuCObMYGU0MeX0akDvbIgSO4FtuhO+xoYs0134AUt15wmaJ8JumongPB44GpSjenvRcQQgUWJtwzPPQg47IkbT5EP0NuuACzBQ6OkYT3Qf3C7NnjZpz2eZaTKSkNJIFgW3q9wAI/O1ylzDFD3u3eOXqVs9fsoDK+iuf0/ZtuBr1yvcBP4TVd8S8WtF5bzmQ==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P190MB0746.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(7916004)(396003)(39830400003)(136003)(376002)(346002)(366004)(186003)(316002)(956004)(478600001)(44144004)(8676002)(26005)(9686003)(54906003)(6496006)(1076003)(16526019)(6916009)(6666004)(66556008)(5660300002)(21480400003)(66946007)(6486002)(66476007)(33716001)(2906002)(52116002)(83380400001)(86362001)(4326008)(8936002)(46492008)(2700100001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?us-ascii?Q?DQB3k6UKP+n2Z1SZCo2+sxKlTNkM0PJh2YiM278RnzPwYmna8pNvdFypJYaC?= =?us-ascii?Q?/KRyDeBY/Pp2KfBu3e1EfqRArqDD7N/FqPi+uhpw1z9BLJQUIv2axSEtwms0?= =?us-ascii?Q?88XSMmGu7DC9iS83kCCNgBZw+h5CxkWF6kW7/Dhbm8sAlP9yBGQZUDknQj19?= =?us-ascii?Q?dnH9AKOeOD1AlMy2jiUgleLrC3uiM9jCJ79psQJLpCZX9YyMahAPKRrT6kej?= =?us-ascii?Q?u2LBbZ45zHET+76dyBeVahGqhcKE+x+OKdPOG++wr1eaCNlEjld76lK6GFoq?= =?us-ascii?Q?67oF+sO6xzvQq5HOK2cZ/Ypd99OCqYMS14cs8myHm2LjrowIKw/xan0gN6av?= =?us-ascii?Q?igcO6er2EigR7QbAz3gtPmzjOLBcad1cjTGAMGMZr/79SLhqSTEQdmZvwAsj?= =?us-ascii?Q?LXL8WlldTUKHNNrzELsT4uJwSX841v+4GkM73HA4ypO95CSAvvAjbMmKaET9?= =?us-ascii?Q?myihQC40U22O8hCQFqZSpf+cSfntUKf7ySimRrJeck5jnwKmfQ5x01K1Nu/+?= =?us-ascii?Q?nZSGzK2QHQlZt3GgKftE38Q4U5GpMihtXXMMS0WIdPbov5NjE/Bo2AZ4bwlY?= =?us-ascii?Q?2fiBAYYM1duwrgHqsh3tUP7g4HFX4hc3xUKXfShrOcyWALb2gmwFOp9iXV9a?= =?us-ascii?Q?dX65CLsME3V0pf0aPFRaaLaw31QeF2RTGVMhWiH59SeVaUoxm770Va/niO0U?= =?us-ascii?Q?Vjsv3EQVxucaUYHTBFuODDwOH37GqbUl+AMmydUnznHDeDPG6MYs04SFp5Al?= =?us-ascii?Q?fWE8rykNU8A3+Fj/8lKcqW2RqWbGciUSHtwfTZdSGrdVIW56pQF8d1rjeYeR?= =?us-ascii?Q?Xby4ACwkvkKeYoovplmLNM1jtlTAoIBRCNTPFQea0XSewffakIMC+dnVcasl?= =?us-ascii?Q?UpKsJE0jUuJSR9TBkD4YhqBTYTKUyB5jVV1PPcL8Kz8RA7gFAr8b4DSVEtyC?= =?us-ascii?Q?IhE0litEzaQEBIiLl/FLUYtISeOM8Si9BXh/VzxllGxq8Q+wbk7aGzkbFQFu?= =?us-ascii?Q?DS4G?=
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-AuthSource: DB8P190MB0746.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jan 2021 14:58:08.1382 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7
X-MS-Exchange-CrossTenant-Network-Message-Id: 03c9f096-d0b6-4e2a-fd54-08d8b70a7920
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XQQbd5pU1Spnp8/QYucMIHuPEDRIOUfu0uVrdpgZtJsQDLOvmqFxB5BxxIXhuTs9mO3o4ZNHS9CBbkELvHHsyw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0453
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/N9dCSvaDI1KdzQs-gPvpO0I6Bt8>
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, 12 Jan 2021 14:58:19 -0000

Hi Tim, all,

Happy new year... hopefully :-)

On 01/11, Tim Bruijnzeels wrote:
> Dear all,
> 
> <snip/>
>
> - 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.
> 
This was kinda the point I was making when I said that I couldn't think
of any use-cases for which multiple RTAs wouldn't work:

The above logic works just the same if you instead have N RTAs over the
same signed data, and require that the union of `resources` from each be
the same as the set described in the signed data.

Doing it this way seems to present the advantage of decoupling the
rpki-validation of the CMS blob from the application-specific-validation
of the underlying data.

Every use case for this will require tooling to perform additional
validation of the signed data against the RTA (at least verifying the
digest, probably more), so this doesn't introduce a new step in the
process, it just moves responsibility for it out of the RTA spec.

> 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.
> 
It arguably also adds flexibility, in that the consequences of having an
incomplete set can be application-specific. In some cases, a partial set
may be useful, in others it may render all the RTAs useless.

When I started writing this email, I was mostly agnostic other than
insofar as this may speed-up or delay implementation.

Having thought about it, I actually think the multiple RTAs pattern is
better than the multiple signer pattern.

Cheers,

Ben