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

Stephen Kent <stkent@verizon.net> Fri, 28 August 2020 14:25 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 3AAC93A0C1F for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 07:25:45 -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 lXgkDTKhpfLX for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 07:25:44 -0700 (PDT)
Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (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 D17B43A0C22 for <sidrops@ietf.org>; Fri, 28 Aug 2020 07:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598624742; bh=gpisv9Ly/AdJ62zGHFHOx4InnBLRStFml8qn8uE6jkg=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Hr7T3gtM5LEJMN8KBHqZCnMsG4fYv34uy3f3caLUGne+Tfe2on1Jr2f0pp/CJKyW8ziTsjVlYlVeUSRPt2i8coXodFSN5TeY4H/x98mUU2AhmDpDsKg1zt3wyChu7BQf1RuIRiXgbim5VQ3xulSbt8J941eOWE+GaZYXhTbDMSXz6/QwfxYH1U0kvL1iWkavN57kzBTMhV1oXWIc56WNspfuscdzQOg9U0bu9FaY50c2PlMEHOIIEgnZLCwJVXT37r89R37MFJaNXoCh/yJWjTc0Ewl4r3J6/Y334vrQyw565o5zAMKd0HIYblb05+TiG2eUCCClDXFx+N+lYC3OHg==
X-YMail-OSG: _BlQw_gVM1kM4Nk95QGpB8R09fikdkVcSPQ3790zFFpRwVqsZ62JUvc.oD6j8oA LI2L6opL_tK9WSRp0Vhq8ZrvzciZOlXzWARxen6spPlVUmm9lvw7v0I4FKncBjBfS6BwiVIJs6Lf IPyMskTLPY4UYOZ_flPPzdTsksiAczV9yOjqeBibQf2iDVlDamLVxOr_Cu02jqqV.kpWJJZfNpbM qWMaAO23zSr3ldzocQ3P2_VhT5pAoe22GDX1kbJSbTN.oy6QsGxPSA_rMWUeLJ3_nQY40Zwp3dLf BOa6U4OMZ2DEws9ubqLmpfwffkDSL346fyBPeAo5idMZ0LTB0q_AElpXST22Flr55K_fm5hMvhEo mIrqmX2qydSsMAUrpR9cvdmU.QRIyr0gJetvS5vTES0B0jIOVJoRab5SlIhG2km5YEVcyHwrw0Ph RwHvUxwXGTwTqxJJF_4E4DSfEXoBkJ8p6.uUlL0duSmXAY12dY7LZH_GRFnMJTTLACmtZIqPwrlh Z6Aby5OsTqprwae3wI24etm2hT2HuvOKz.2aJo1dpNcW202uXcDJnzxFc0qmW4_xn.IdrqX9xmAm 98C_vQ5JysZip9HFjYM.i016jW4bXqfUcQ4Qj_Nz4OIcNEIf0If7u.KUDD3kXGLYZxWVRUpVmz8g 6WF5.Sg7X0CubCdrjWKYRVJXAfGuaOx05bsV9jSdH5pKEkJHv3JLzFi7ayW3ZvsVtNYxVs4ZtCRv rkE3GZbmmVxXRV9GGzfEk9du50YYfnhYongBJEq4dfQAe72DVJzwFDWU.8GlCI0J6HdjGy2yREO2 gVsbE9.ZJHi.RXwWNMPG1B.8JnKMKcmFkYhbLUWRkWS1uycY0XSr15oXrWwK8mmj0KH4CKfrkHw. YPanrJWqVjlDKdOvsGHS7ujKFahuPLTpmbTSZx1b_06EgxvHo5ttac1ZsEos7uOhZCcxSInEWKmF Yd3gOWDLfc7N2TjqXkq7dN7RTMIhdDQbbqBPeqwxQniBna2ygOXZNDe7rb38K1J8iuG3uQaWfPwB XrsXfDnPm1ZLhggYpNs9IVAHecdZdfhwN6hUfUZUCBrYYWBTV7cXG_iPVURBhDCUT1DFAfp.BKq3 DqL03hpd57r155aPqwaQkaB1UP9pq9P9m2cESWvPixl8e7dHLRimJqYssc0hzZ7.jgJu7Xhq_aB5 wcRVsGpUC_lIFAUbYxpWSzuGNce8rNNB49Z6Kbp26P12I9Gaurf3B0fYhkk26bF2fg.8j6L2QdHk ehXNxcYuvHMrA0rZjv3xg0On_VVFExvEfFl8wjdZ5w25koTmleoDGGY7GlAU.mWFU1GNHAG.x.Uo yzIdcQRF9YLvumkkAnfYute9u4EuI2zddSK8zgoTSPfRjDSOEJMZ4MXYLZagK7nXS5wNR9a5IR0I 7wx28gIGz.icV3JvcHry6NOFzowEA.L562SBUup18WXPwasGP2uRt4A6B4suFdZCBQHZ_5EC0HPL hzszA_wCXpx0GvszGrSKAxDZdepzK2BkHOxuaJuK_OOXsOjhEjWtZmZ4iR55EBdLqBw.tPN5y7jQ dW.vStBYWACeGs2WWH.z0
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 28 Aug 2020 14:25:42 +0000
Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b4e13331f9e36cb503d78fd2be8ebbbe; Fri, 28 Aug 2020 14:25:41 +0000 (UTC)
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>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <aa23510d-b418-a345-76b7-d970930284f4@verizon.net>
Date: Fri, 28 Aug 2020 10:25:40 -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: 7bit
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/tEskrcZ0KiCHa5WuwLjNsffB_i4>
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:25:45 -0000

Tim,
> Should any and all violations of spec lead to the rejection of objects?
>
> Arguments can be made, are being made, that in the context of security the answer this question is 'yes'. It makes for a simpler world, and simple is good when it comes to security. There is no slippery slope anymore. Taking this even further one can argue (in the context of manifests) that if an RP knows that it has *all current products* of a CA, and the CA clearly messed up even one object - they should no longer be trusted to know what they are doing.

The issue is not whether a CA that makes some types of errors cannot be trusted to know what they are doing. Rather, the issue is that, absent feedback, a CA that persistently makes such errors will do so forever, forcing all RPs to accommodate these errors. This IS a slippery slope; it paves the way to more serious errors to be tolerated, based on an established pattern of accommodating sloppy behavior.

Steve