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

Tim Bruijnzeels <tim@nlnetlabs.nl> Fri, 28 August 2020 14:55 UTC

Return-Path: <tim@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 3A20D3A0C50 for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 07:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 eGINiFcvoGcE for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 07:54:59 -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 9DD503A0BC8 for <sidrops@ietf.org>; Fri, 28 Aug 2020 07:54:59 -0700 (PDT)
Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:756d:96d7:8934:5a50]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8BC2C1B92A; Fri, 28 Aug 2020 16:54:56 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598626496; bh=lEYGeWYB2M9XWOuJvd9FQpN9BnhgxPBxZ5OelEH3J1U=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OV4O4D5AdFeSqa0gJaac7DwumNtG8x7Q9Gg/9qTw2nrYc6IMEFljqfFwus6Suf/h+ TCdcgbbFB5bgDovsIRPYjvgLjN+xbqIjS59C9ylypsLecTKwg6SP/UFjWRTJyvZtKL Mynhl/YAnljxAgUhtQsBNo6tcALNE+EOgrmgG5eU=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net>
Date: Fri, 28 Aug 2020 16:54:56 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <10CF100D-9B71-4FA8-A3D2-2A9933B6D9E5@nlnetlabs.nl>
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> <045cb11f-5eea-1568-5260-d9794143dc7a@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/-OWMJLD0p60bfTBHCfXkyyAAQNA>
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:55:02 -0000

Steve,

> On 28 Aug 2020, at 16:00, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
> 
> 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.

I believe that strict conformance is a laudable goal, but I also think that given that none of the RP software has been doing this until today CAs should be given time to fix things.

If we ask all CA implementors to test their repositories with strict compliance validation options, then I believe that setting a flag day for strict compliance in future can get us there without impacting current operations.

Yes, it implies that we accept that things like using the wrong type of 'String' for a Subject, and even BER vs DER encoding, are not critical security errors.

> 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.

No, I do believe that strict standards are desirable.

What I was advocating is that MFT are treated strictly by RPs to determine that they have the full set of statements made by a CA. This protects against issues between the CA and Publication Server, and between a Publication Server and RP.

Going beyond this by saying that if a CA makes any mistake we should disregard everything they say has implications that I outlined in my other email. I think there are scenarios where security is not impacted (e.g. GBR vs ROA). But I can live with it as long as the WG understands and accepts that there are at least two (temporary) failure scenarios where the issuing CA is not to 'blame': inconsistent (rsync) fetches and resource removal timing issues.

> 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.

As I said in my other email, the suggested change that all listed objects in a MFT are valid makes incremental much harder than before. Therefore it is something that needs to be considered.

I am not going to repeat what I said there, but maybe you can reply to the specific points I raised there, and suggestion I made that incidentally would not cause any delay on this revision.

> 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.

See above, I think we should aim for a flag day


Tim

> 
> Steve
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops