Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report)

Stephen Kent <stkent@verizon.net> Fri, 28 August 2020 14:00 UTC

Return-Path: <stkent@verizon.net>
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 4E4A23A0658 for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 07:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 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, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 Vhk5AxDO7V4S for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 07:00:20 -0700 (PDT)
Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB373A08B0 for <sidrops@ietf.org>; Fri, 28 Aug 2020 07:00:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598623219; bh=ua3x9Ywt3AQ4IPMT+Kuevv9ogfPBsoxx8YTEazoZO9U=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=VP/EhdpqZgFSnS/Lez+lMIIpWMpJ3RpCf9zO9mmF+eXdNljhcDmpjG6EycSRgE979sA+XlvBFxFqjzYuON5xNNDKaoYBGur5uesMnqUUUaY128lbFzVxk6QnnCPoRt3FqBtvmGbEq0QpAIOjGpptXBVConY/cE1j/7v318+WwGDgV6BwY/ACc52M8JO0QbuLr3mWmZPT43DOTqM1oCAC+ZCCUVbWdeHi4bMMa23MSjNsQR30ZumSX+h7BvSIxFfttyhtOZsnj4BTirKZ38MAQzxd3eJrXDmPn36bb6VIbv33oLxbv5EkJj091jt6mYqnisSk8wFu5BqEGOT2/hTLsQ==
X-YMail-OSG: LC9lo2oVM1kOYC4_lrQE43ycWWjQeKre0lVYyFSei.HWuCvN_Dfn434AHYbi0lB 1d6jxorWJSHvY1HXNsv98g97PSFlVus5WIMpWdkxLyYt2l0oXJ1.woEaqXaYKRb8_LNf.TpQvjhb 3pIc9IroOOSEk3xyrFM5fWOLij_xnEVyiLsUwNb15.hDqJnVjE.TRGYS6bqWUp8SOdIiSZEosmJu tUhwE9vuR1hyrMLEZAfwfE1g7C3oQ979gheH.LgNF8cDo45zU9fZ28yf1uxPYXK0_.BT8OyGncA5 PEVWqHW_saALtYqJvRvlRNW51a1BgIFi9z2IX4Mhil5mRwcE7jpcNCyOSBZ26k_3JFKTG5DFBt8X eyOtxHYjNMW3mAbrpTq7GR5iGTQccCfF6l8eg6wvIuhF6bry7I498s_5beIOTuVnUMofGFmyM2Tc OJc1DydRaPvlbpsOAVs0CEPrRj9falrw8DRa_EbdjD75WRhlZUMlDlGvJPHW8kgxlnGwpHASoSmt Bs.jfygr1ctUMSXUsKMA0eKxWKx.FzcFOW62kNIYc7EU7QWfpW8b29fQCa3KgYJiUBMCfw6fYPRJ 8fwndq1zxsVMiH9eqsEeOcT1R7qeH2.x9BrDzNo4H9ddkrPBEVPWvGFVLQCtWl._1uhnDrThOwXL ZzTKKKkJxVtmcuCdlR4aGJc7wjRuVT7_Wms13.YSwLUH8TQDOH1kccVLzwQRpHaGp4lxEAZgB_0H yO4PCg.kR9P52E5ZFDy..gB48xxYMzG9SzPCIERPHy6rs3aUAQYnYiI1iuX77QIti1PiPiOUzAY4 pChfrU__5tXJwdBj.1n4XuPfDrE62rdKrVkbvgDNOSlqqbgvi9FDfpLuWW0oYOSY9H4L.b2k3x.c FH_h7qz9Yx2mjKrQnwBepqiNX07WSSVGOchBp4t512yQ9WHHft_bvg2r8Purxb8sa3fIEDX6bJ53 gzu1ND8FDpGtjdznLnoVlx1BfbfaUwKCdTuUM4gaLX.21JstOyn5BC538L_WTNrL9sunyyP61GVE EXNq0dSytB3l85ryQxA_kKaSG041J6uVZ0jeeBun9p39LSGZegERF67qlD4XGDLai9Qyb1b5hKKP s5RGbhoJjl66CKe47pUEnrPYDdu9SLgeh7n7j_njlaLRcOr0Qo0j4l67_BanRulCMgvl96o2lRei D89fYdhNR8B1tNjflGrJj3v6ro6L5aSOFGuXzPylFVdsJKZ3S0RcMZDkLPk7.d1LtTY0XrV7KAex g2i0Q536xrOvFM525BpTSBOKXDYWYwVPDWr9oRVnT.hhoayPJA8e9Uf495wDAyQ5Godtz1kBc9nM Hu_o0Bso89zPOeI4VP3YUOGt7fjh6xk0ZOs2d9f.QssW3KxFX3nR0gXyL5sxkmOMiN.QnOlv5i6A 6OSrNTNXIIqOnX4VEuE7xY55LXueEcmJDE3Atim.liIOGRMgSPxFYRqTlIIOk9skHrEjdPwRVtrx qJ8IE75dWlYZswNQTD_Ud3IxdZw7qjSwO6iQ9TLJUrRyQtri8X62ztXK_EfYE45S0ubTTTk04Fgm N0RR5vBSEO5mDktoFw5eSzPQbzJV6PQ--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Fri, 28 Aug 2020 14:00:19 +0000
Received: by smtp419.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a9a21888e6c0310dd3f8df5d9a1b739b; Fri, 28 Aug 2020 14:00:15 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: sidrops@ietf.org
References: <DE33EFAE-FBD2-478F-92A9-1FBD81CCC43F@arin.net> <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <20200827142827.GC88356@bench.sobornost.net> <DEBF83EC-B5B7-490B-9F30-19571991E273@nlnetlabs.nl>
Message-ID: <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net>
Date: Fri, 28 Aug 2020 10:00:14 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <DEBF83EC-B5B7-490B-9F30-19571991E273@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/KcmUUuW1xrx2j48JYGDVvjC7zv0>
Subject: Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report)
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: Fri, 28 Aug 2020 14:00:22 -0000

Tim,
> ...
>
> @b: the robustness principle and security

Jon Postel's robustness principle is appropriate for promoting 
interoperability, but it is not a good principle for security. Security 
requires discipline. In my experience, people are not very disciplined, 
and thus we have recurring security problems. Experience shows that 
without feedback, people are not motivated to become more disciplined, 
and security problems become worse. Thus I feel is is critical for the 
community to reject RPKI repository data that does not conform to the 
RFCs, as a way of providing feedback and improving discipline.

The revisions we have made to the manifest RFC are intended to remove 
ambiguity and to impose strict standards for how CAs manage the data at 
a pub point. We all seemed to agree that removing ambiguity is desirable 
and necessary, but not everyone seems to believe that strict standards 
are desirable. I defer to the WG chairs to decide what the consensus 
position is in this respect. However, at this time, suggesting that the 
manifest RFC needs to specify how new objects can be incrementally be 
introduced into the repository system is a distraction. I can envision 
one way to do that, as noted in a prior message, but that would entail 
changes to several other RFCs, and will delay, substantially, progress 
on revisions to the manifest RFC.

I am very bothered by the observation that, if were were to strictly 
enforce the requirements imposed by the RPKI RFCs, then the number of 
verified routes would substantially decrease. This seems to suggest that 
it is more important to be able to cite big numbers of verified routes, 
to convey a sense of RPKI deployment success,  than to "encourage" CAs 
to get their act together and follow the standards. That, I believe, is 
a mistake.

Steve