Re: [Sidrops] nlnet rp and rsync

Martin Hoffmann <martin@opennetlabs.com> Tue, 12 May 2020 09:53 UTC

Return-Path: <martin@opennetlabs.com>
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 3ED313A0D48 for <sidrops@ietfa.amsl.com>; Tue, 12 May 2020 02:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 1id1ujTQ9tG5 for <sidrops@ietfa.amsl.com>; Tue, 12 May 2020 02:53:09 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 B8CBF3A0D44 for <sidrops@ietf.org>; Tue, 12 May 2020 02:53:09 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 45F1133F23; Tue, 12 May 2020 11:53:07 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Tue, 12 May 2020 11:53:06 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: Randy Bush <randy@psg.com>
Cc: Russ Housley <housley@vigilsec.com>, SIDR Operations WG <sidrops@ietf.org>
Message-ID: <20200512115306.04c6085a@glaurung.nlnetlabs.nl>
In-Reply-To: <m2k11i2x7j.wl-randy@psg.com>
References: <m2mu6f42ji.wl-randy@psg.com> <B23AED42-5983-4E14-897A-03A51FCDDC42@nlnetlabs.nl> <m2zhae3hrh.wl-randy@psg.com> <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl> <m2y2py3emb.wl-randy@psg.com> <FA1358BC-54C0-476B-A8A0-238D2F4EFE74@vigilsec.com> <m2k11i2x7j.wl-randy@psg.com>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/08JJP3F-lh_h4KYowxn_3ozwdpE>
Subject: Re: [Sidrops] nlnet rp and rsync
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 May 2020 09:53:11 -0000

Randy Bush wrote:
> rrdp is more fragile.  e.g. the nlnet labs client (rightly, imiho)
> checks the full certificate chain.  if any piece of the chain expires,
> is CRLed, ... the client does not go to rsync.  bam!

I would argue that operating an rsync server is much more fragile in
practice, simply because operators have much less experience with it.
As opposed to keeping an HTTPS server up and running which is absolutely
essential to each and every Internet operation now. 

If a certificate appears on a CRL, there is probably a good reason for
it and perhaps the service shouldn’t be trusted anymore.

> falling back to rsync is not a 'downgrade' in that the rpki uses an
> object, not transport, security model.

It has been demonstrated that by maliciously withholding RPKI objects
you can cause damage to the routing system, so we should perhaps
revisit the choice of not relying on transport security.

> the goal in rrdp was to make the rpki more, not less reliable.  we
> found the nllnet labs misfeature in the wild when CA data were no
> longer fetched.  imiho not good.

Was that a permanent issue or did the CA in question fix their RRDP
service in due time? From what I am seeing, the current shift to reject
stale manifests and CRLs will cause much more issue.

Kind regards,
Martin