IETF Logo Mail Archive

Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06

Russ Housley <housley@vigilsec.com> Mon, 03 May 2021 16:14 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38373A1A9F for <secdir@ietfa.amsl.com>; Mon, 3 May 2021 09:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 7OWET-gWLYCk for <secdir@ietfa.amsl.com>; Mon, 3 May 2021 09:14:03 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A98B3A1ACF for <secdir@ietf.org>; Mon, 3 May 2021 09:14:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0E0FB300BED for <secdir@ietf.org>; Mon, 3 May 2021 12:05:46 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3HqUgtaexvFi for <secdir@ietf.org>; Mon, 3 May 2021 12:05:39 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D1764300BE0; Mon, 3 May 2021 12:05:38 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <BF277402-4404-4D0D-9027-826C169E1A6F@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7786BE36-6819-4952-83BC-462332B516A3"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
Date: Mon, 03 May 2021 12:05:39 -0400
In-Reply-To: <CAJU8_nXr9MVefjgNxatfuAEWrvp+TzwLN3zGO8TVRmDJxTEoSQ@mail.gmail.com>
Cc: Randy Bush <randy@psg.com>, Last Call <last-call@ietf.org>, Ops Area WG <opsawg@ietf.org>, draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir <secdir@ietf.org>
To: Kyle Rose <krose@krose.org>
References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <m21rasx3tc.wl-randy@psg.com> <CAJU8_nW2aA1SFjeAwzK+CYHPyQqJHLKYu3J9H91NpYfqhTYBWA@mail.gmail.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> <CAJU8_nX-Timmuvv=vBpgXHYnbCLAd2ug-=BLy_Xp08ehLkGv9w@mail.gmail.com> <F6F67CB5-C824-4DA7-A85E-06EB4EBAD101@vigilsec.com> <CAJU8_nXr9MVefjgNxatfuAEWrvp+TzwLN3zGO8TVRmDJxTEoSQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/1jgYFew6BXR3AQ8psNUS3k_5604>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2021 16:14:09 -0000


> On May 3, 2021, at 11:44 AM, Kyle Rose <krose@krose.org> wrote:
> 
> On Mon, May 3, 2021, 11:28 AM Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
>> This is not quite right.  It is true that theWebPKI provide authentication and integrity when https:// is used, but this is not required.  If http:// were used, and the file was modified in transit by an attacker, the RPKI signature check would fail.
>> 
>> Yes. Which is why I'm suggesting that you mandate https.
> 
> I do not have a problem mandating the use of https:// for authentication and integrity protection of the file.  I think that is shown in the examples.  I am saying that doing so does not "chain" the trust models.
> 
> Explain how an attacker could get a client to accept a forged geofeed data file authenticated as I have suggested, because I'm not seeing it.

We are not understanding each other.  The RPKI signature will prevent the relying party from accepting a modified file, regardless of the means used to fetch it.  For this reason, there is no need think about the interaction of the RPKI and the WebPKI.  No dependency is being created.

Russ

v2.23.0 | Report a Bug | By Email