Re: [Sidrops] adopt draft-ymbk-sidrops-rpki-has-no-identity please

Martin Hoffmann <martin@nlnetlabs.nl> Thu, 25 March 2021 07:26 UTC

Return-Path: <martin@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 490843A1398 for <sidrops@ietfa.amsl.com>; Thu, 25 Mar 2021 00:26:32 -0700 (PDT)
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, 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 SBljqV5gvpGs for <sidrops@ietfa.amsl.com>; Thu, 25 Mar 2021 00:26:26 -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 18EA83A1399 for <sidrops@ietf.org>; Thu, 25 Mar 2021 00:26:25 -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 1C7F260D3E; Thu, 25 Mar 2021 07:26:21 +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=1616657179; bh=9nun+mvqi1d9EmPcHHAEm1UE2skmMWvzejAA2D7+OtU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gG9OWfTog3l/uhVY8Q8TBdWX0bg97hHhJIraBGfrOHiercmxs/i36t275hbV4ss6t CUOg8TIuvxY8EK7+5SUz+lVEsnRDUxPTtnhT+ah7ffnsw0kKHlxbx++mI4y1prSyt7 31bgKpV1hW/QyvUMPyyBM5g4OA4E4hCapLlN6OrN8CA9Ix7S/EfBgHLP9AoiPchoYm fdCUcebeluOuaB6yR0BOjAIqI+ebk8J+0LukMYuzURiHYo0ywCl/b7W72sAJkS4LY9 /pBCbGR4rVRJMLTvTkPD906yIX5NKiH3aXnkDQawYuYc+qmS0sgP5WAwAXUirEu5lQ jWxAvGDB/WKmA==
Date: Thu, 25 Mar 2021 08:26:15 +0100
From: Martin Hoffmann <martin@nlnetlabs.nl>
To: Randy Bush <randy@psg.com>
Cc: George Michaelson <ggm@algebras.org>, SIDR Operations WG <sidrops@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
Message-ID: <20210325082615.3c3322f5@glaurung.nlnetlabs.nl>
In-Reply-To: <m24kh0xed9.wl-randy@psg.com>
References: <m2ft0sgwfy.wl-randy@psg.com> <alpine.DEB.2.20.2103231615441.21528@uplift.swm.pp.se> <m2pmzpz41r.wl-randy@psg.com> <CAKr6gn2BWm0ZwuqwLc=g7FXgqbt0eqJ3tWJW7BzP=vEn6qCEcA@mail.gmail.com> <m2mtutz3s4.wl-randy@psg.com> <CAKr6gn2YM+5+3BMPUPM0O-C_VP5dprQyOyXkxvAKDhP7tfDbyQ@mail.gmail.com> <m2im5hz2qt.wl-randy@psg.com> <CAKr6gn3m6aBV_PkZQQfnEg2R5M92kfJhvGfAiu-3XW++bdR=1A@mail.gmail.com> <m2ft0lz0h3.wl-randy@psg.com> <alpine.DEB.2.20.2103240715470.21528@uplift.swm.pp.se> <m27dlwzaiz.wl-randy@psg.com> <CAKr6gn2Vr-n=Nh=4ivukLWmHzM52iUWt2F=05tXcSs+M_vXYwQ@mail.gmail.com> <m24kh0xed9.wl-randy@psg.com>
Organization: NLnet Labs
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/N8jFBTAybbR19p0lr4p5CGrccrs>
Subject: Re: [Sidrops] adopt draft-ymbk-sidrops-rpki-has-no-identity please
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: Thu, 25 Mar 2021 07:26:32 -0000

Randy Bush wrote:
> 
> when
> the monkey uses its CA access credentials to cause the CA to sign some
> document/object, it is the primary actor trying to fool you into
> believing it is a rabbit.

Keep in mind that these statements are not protecting the issuer but
the receiver. As such it is the receiver’s task to assess what exactly
they can reasonably deduce from the statement and if it is fit for
whatever purpose they use it for.

In other words, if you believe from a bunch of signed carrots that a
monkey is a rabbit, that’s on you.

I don’t think a standalone document stating what a signature derived
from an RPKI CA means (or, rather, as is the case in the draft, does
not mean) is necessary. Instead, discussing this in the security
consideration of the document defining the signed statement will
suffice. Again, it is on the party accepting these signed statements
to do their due diligence to protect themselves from liability.

 -- Martin