IETF Logo Mail Archive

Re: [Sidrops] what to do when the CRL is hosed?

Ben Maddison <benm@workonline.africa> Mon, 24 February 2020 23:35 UTC

Return-Path: <benm@workonline.africa>
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 8F5273A1162 for <sidrops@ietfa.amsl.com>; Mon, 24 Feb 2020 15:35:01 -0800 (PST)
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 (1024-bit key) header.d=workonline.africa
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 VX9UK8EyT6Hq for <sidrops@ietfa.amsl.com>; Mon, 24 Feb 2020 15:34:58 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::628]) (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 662993A115E for <sidrops@ietf.org>; Mon, 24 Feb 2020 15:34:56 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EwUSWQLMseafn77KLPtN84yerQqCMjUEueLTNdIsKKvRTFbAiRoW4JcRWTQUlcN64vvjePVdbRP93xU9CO1uletfPxOBP80xCn3dhwImvJPyGgnjUJbOSvXYtO7M/JjwMFuHu6GMnOa3rq7fge1KBq93xZZ00r84obKdcx33m0tVrT+cPkArqa6YIxY+5TaMX6r2ybnKRxm229TFj8O1AyTfBwxwiL/b1wOe26PX5WrAOInrjHTwpBlUoj6KLpuiXwyjaGbfcpJocVc2Q3VWBLkrjNI2wPY+b8M9UzEL3HqXtre43bwdvU09/u3SNt6UqBT5faCg3NanCsYD+c+M6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8ETEkCTNGVCPw+Z0okRj9TBc/CgFJ9yIUe5A4Ghb5OE=; b=WE4eeUn528qKjh7bZ30npIBuq7A/XfOHWCaPMq3hhu/v+PTOCNJiZg6ktPLZuOaCfbtPRWngBIZcOzn5J2pky8q5nI37JCzSDTH8r3YGoJFYmKhqKGJ2abcAo3DlkroR1sq3VrdwJ8vPUhEUc2m9jKZ+W3ApvWZn3Vf29p9ZA2sHj8z9ABFUZgZNryVegnZEQ04kmPNmA6DSXwLu6arIa2ZWG6Cs69XqPuOSCXROyaXAN8L828cCYaHEgrcQQhjy95T1gbB8zFbk3MeZPTl7GmjJM7gP+rn4yKTXDOQgfa77yQ6sTD5zbmE8oqOcKImyBJQ5EcbTqMAcL/wEMHGqqg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=workonline.africa; dmarc=pass action=none header.from=workonline.africa; dkim=pass header.d=workonline.africa; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=workonline.africa; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8ETEkCTNGVCPw+Z0okRj9TBc/CgFJ9yIUe5A4Ghb5OE=; b=HgnuYI0JOfViqLdkP36Sq3sYx6K/XSP1VcVUBVCtQNlP1fxx2f0buMHT7IiUHpgs4FWPgPg+Blh8DUtTYfwlZAy8Xno3EICTPhqZLzU6FYMbcNEUlUgwLx8Sa8DMBQbDTH/t02uLukaSy0BfA1RFN+98nuPttwbeVAon6Ukg1jE=
Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM (52.135.56.21) by AM7SPR01MB0005.EURP190.PROD.OUTLOOK.COM (10.141.189.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.17; Mon, 24 Feb 2020 23:34:53 +0000
Received: from AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::acf9:986c:23f6:da2f]) by AM7P190MB0583.EURP190.PROD.OUTLOOK.COM ([fe80::acf9:986c:23f6:da2f%5]) with mapi id 15.20.2750.021; Mon, 24 Feb 2020 23:34:53 +0000
From: Ben Maddison <benm@workonline.africa>
To: "job@ntt.net" <job@ntt.net>, "jared@puck.nether.net" <jared@puck.nether.net>
CC: "claudio@openbsd.org" <claudio@openbsd.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] what to do when the CRL is hosed?
Thread-Index: AQHV6yVOp0IS38hLHU+bnXCKrcyzWKgq2MyAgAAR5ICAABUKgA==
Date: Mon, 24 Feb 2020 23:34:53 +0000
Message-ID: <afc2205897c9a2ed16ea8eae6b36243c949df2bf.camel@workonline.africa>
References: <20200224211531.GB60925@vurt.meerval.net> <10259FC6-FE65-4B34-81B2-A37FCFA29BF2@puck.nether.net>
In-Reply-To: <10259FC6-FE65-4B34-81B2-A37FCFA29BF2@puck.nether.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=benm@workonline.africa;
x-originating-ip: [160.119.236.50]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 70a0cdf0-130e-4419-5b0f-08d7b982264a
x-ms-traffictypediagnostic: AM7SPR01MB0005:
x-microsoft-antispam-prvs: <AM7SPR01MB00059155B3198D1899E46761C0EC0@AM7SPR01MB0005.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 032334F434
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400004)(136003)(396003)(346002)(366004)(376002)(189003)(199004)(91956017)(5660300002)(76116006)(2906002)(4326008)(66556008)(66476007)(66946007)(64756008)(66446008)(86362001)(6506007)(6512007)(71200400001)(508600001)(6486002)(8936002)(54906003)(316002)(110136005)(81156014)(81166006)(8676002)(53546011)(26005)(186003)(2616005)(46492005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7SPR01MB0005; H:AM7P190MB0583.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: workonline.africa does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: t0KeMQwuV0NuR4Nip9BOyY+Hxd0d9lHNMVZtwZjgGzNjc3pHe/7ChrZ9qsYAFPA7vsPr2LtXFxAFEM6yzXuxANb1HpNoUJHFlZrrP5/m4tonaElNJuU021Zxi7wM/vwY0vkxab8vCeordAxDIaPtAz3CIQXVQhbGfyYLARPDwSxmT4YE4xk0ETlnnT0kfVcvqp54rd4vQbi9jJsJ+NNis7GvXNLWG8ho/hOvhxPD5VgycBOExCJh84W37viARV3RLoh6gPd0NAbt3kZhz2YLnNlFzzUOTmF9ODKjy3Zz9p0o5Zdl3ZZOxu5iQi3YyYWSozC688BKHriqQbEVgyHtRgZBhr7RHcTQrDWOICmer3RsnIEw2MXzUIRP00zUAz5BqxoqipINj1wD/jPRK74ZOtrdwc8wPbGUoF0I76Hx9mqcHjI88JtN1bcj5Exv5aTyQt2V56g4m1uoC4iu0PvHSNwwGfxzTT0fiH5Z6EtcWPrxHb1wIaYecPgzr2WfSb2e
x-ms-exchange-antispam-messagedata: gSI/yPGNsiPb+WejFdjErId8iUGGLDxB8NI4TGfifrUQkzt5oXVR+Rl0g98yL8c0tNIL5/W1jrqAMdhaEDBPIxf+w3H97oAWryPAHR6gqbql1enqQR6wUK1Sp2T5/jb3e9352lOmnfQxb4N3NY7/sA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A5AB554CF854D94DA7DF0C50049ACB9E@EURP190.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: workonline.africa
X-MS-Exchange-CrossTenant-Network-Message-Id: 70a0cdf0-130e-4419-5b0f-08d7b982264a
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2020 23:34:53.5239 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b4e811d5-95e8-453a-b640-0fba8d3b9ef7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mMPI4cqXJQnvRx/ky9n6rFWmZQt47Yq9Lmu9tAq9aOAl7hgxPS1yTf1Fj1+de2ho23gNDzzaMb5n+GLwxFg85w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7SPR01MB0005
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/-Jd78_WMKZT89yBAYXLUXDZZU5o>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
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: Mon, 24 Feb 2020 23:35:02 -0000

Hi all,

On Mon, 2020-02-24 at 17:19 -0500, Jared Mauch wrote:
> I think you may be right in absolute terms. You are likely wrong that
> unless you have cached CRL experience saying it's bad you have no
> reason to distrust. 
> 
> Also cryptographically signed data can be sent insecurely and be
> validated against change or tampering. Perhaps you are worried about
> privacy?
> 
> Sent from my iCar
> 
> > On Feb 24, 2020, at 4:15 PM, Job Snijders <job@ntt.net> wrote:
> > 
> > Of course - in making strong statements like this one I can not
> > afford
> > to assume I am right, so if you disagree - please tell me how I am
> > wrong
> > (in detail :-) ).
> 
I think (strong not-a-crypto-guy disclaimer, etc) that Job is right.

Consider the case of a private key compromise that has been discovered
and the corresponding certificate revoked.
An attacker with access to the key could MITM the hosting rsync repo
and serve a stale CRL that pre-dates the revocation, and thereby
continue to create valid-seeming RPKI objects or replay old ones.

I've had a quick scan of rfc5280, and I can't see anything that says
what revocation status should be applied by the validating party either
way. Perhaps I'm looking in the wrong place?

My instinct says that an RPKI cert that has the CRL Distribution Point
extension should be considered revoked if a valid (inc. unexpired) CRL
can't be retrieved from one of the listed distribution points (or
through some OOB means).

Cheers,

Ben

v2.23.0 | Report a Bug | By Email