Re: [Sidrops] [WG ADOPTION] draft-yan-sidrops-roa-considerations - 04/16/2021

Tim Bruijnzeels <tim@nlnetlabs.nl> Wed, 31 March 2021 07:23 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 E31FA3A1DD8 for <sidrops@ietfa.amsl.com>; Wed, 31 Mar 2021 00:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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_DNSWL_LOW=-0.7, 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 pd4_-uSUa0Tc for <sidrops@ietfa.amsl.com>; Wed, 31 Mar 2021 00:23:46 -0700 (PDT)
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 883083A1DDF for <sidrops@ietf.org>; Wed, 31 Mar 2021 00:23:46 -0700 (PDT)
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 34A19600E0; Wed, 31 Mar 2021 07:23:39 +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=1617175418; bh=IUT9OrITmASsX4dtQ1BlD31ExPsumxFTAg9SyaDHxQE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=cDfW/H+K3lnMk+iYXVhxS2YuB9H4/UfNuJkzdNnmIfG11jMTKrXsJNiCw8q4SbX8z A4lAgY7LHJUFJ61cuyS6RksJX/wdqGS/fHQdYBpvyWbRfHugwnPHxk1/wgl/CCUp06 JpdaYFPwWqgWj93x5Wbj4SJOz+JcdksYi3z2M0eU+v3O1W4zBp8Wvo73PVapRf9bLW S6DhgJXo7PIYBrwjmhFtrDmPFZO1n4+z3/LxiCFtEDpR+miYJJ1i47Kyq+Gd3b1A2u M6/ZwCraaQW2oZePuumvBHoEgA6dZAL6QwFB8lCz1dBD+Wl1yGuPGlbE3v/ruI13yt aMHTWn0xScFjA==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <m25z18o1vz.wl-randy@psg.com>
Date: Wed, 31 Mar 2021 09:23:36 +0200
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B560256-9173-497A-9E07-49566408AEB5@nlnetlabs.nl>
References: <87lfa94xyj.wl-morrowc@ops-netman.net> <67F48899-3B77-4722-B467-F73D50DF1006@nlnetlabs.nl> <YGL2twQ2eEsMQHPq@snel> <8BA83ECF-3D1A-4057-9E24-46CDA779604B@nlnetlabs.nl> <m25z18o1vz.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/1KnJznZC0mRUJA7JmOJ0jKEncDU>
Subject: Re: [Sidrops] [WG ADOPTION] draft-yan-sidrops-roa-considerations - 04/16/2021
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, 31 Mar 2021 07:23:53 -0000

Hi Randy, all,

> On 30 Mar 2021, at 21:52, Randy Bush <randy@psg.com> wrote:
> 
>> I have been thinking of proposing extensions to the publication
>> protocol (RFC 8181) to make Publication Servers somewhat more
>> responsible.  For example they could enforce quota both in terms of
>> number of files, and size. They could also verify objects, e.g. only
>> allow known types, and only allow objects which at least parse.
> 
> why?  we need more complexity to give misconfigurations, bugs, weaseling
> on specifications, etc. more places to hide?

Because of third party publication servers.

Malicious/misconfigured Publication Servers and/or malicious/misconfigured CAs publishing in those, can lead huge broken repositories which can be abused to DoS RP software, as well as to distribute all kinds of less desired content.

Ultimately the response to this is reactive: parent CAs can revoke, or RPs can blacklist a repository (e.g. for using 1 TB of data).

When I publish with my CA at a third party publication server, then I would much rather do so at a server that applies some very basic sanity checks to prevent that my content becomes collateral damage of someone else's actions.

>> The problem is that a delegated CA may not find out that a parent has
>> shrunk their resources until whenever it happens to send them a
>> "Resource Class List Request" as defined in RFC 6492
> 
> my memory is that the child is expected to Resource Class Query before
> doing anything with resources it assumes it still has.

The problem is much more likely to arise at another moment. The objects that were created were just fine when they were created. For what it's worth Krill checks with the parent every 10 minutes. But this still leaves a gap where previously issued objects can be seen to be invalid.

On the remote chance that something changed in entitlements just when operators are making a change. I do not think it's wise to block network operations on every change to ROAs with a call to a parent who may not even be available right then and there. Doing so would increase the operational co-dependency a lot. Child CAs would not just require that parent repository is available, but also that their RFC 6492 functions at all times. Furthermore the issue may be higher up in the chain and the parent may be unaware.

Also, if the CA gets additional resources on a certificate, and naively uses those in ROAs or anything *before* RPs have found the newly issued certificate, then again the child CA is seen to create invalids.


Tim


> 
> randy
> 
> ---
> randy@psg.com
> `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com`
> signatures are back, thanks to dmarc header butchery