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

Job Snijders <> Tue, 24 March 2020 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8BD93A0CF4 for <>; Tue, 24 Mar 2020 09:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EhjZyiNsqP6a for <>; Tue, 24 Mar 2020 09:54:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF3573A0CE8 for <>; Tue, 24 Mar 2020 09:54:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 00E70220162; Tue, 24 Mar 2020 16:54:34 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal []) by mailauth.nyi.internal (Postfix) with ESMTP id 7043927C005A; Tue, 24 Mar 2020 12:54:32 -0400 (EDT)
Received: from imap1 ([]) by compute3.internal (MEProxy); Tue, 24 Mar 2020 12:54:32 -0400
X-ME-Sender: <xms:Rzt6XvVsHw-cY_3QKUKs3e4iFDqQyPUEcPDk_96j9oOcEk7gN8l_dg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehuddgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedflfhosgcuufhnihhjuggvrhhsfdcuoehjohgssehnthht rdhnvghtqeenucffohhmrghinhepiigunhgvthdrtghomhenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohgsodhmvghsmhhtphgruhhthhhp vghrshhonhgrlhhithihqddutdegjeeludehkeegqddvfeeffeekfedvtddqjhhosgeppe hnthhtrdhnvghtsehsohgsohhrnhhoshhtrdhnvght
X-ME-Proxy: <xmx:Rzt6XvtTIL_fZLS6A9FrQ_6w0MaLLqLxl-WrSJEpeVzm1dBqn0oEEg> <xmx:Rzt6Xq5RNEsPgVLGn8ByayJlRZC5mq8ahOyH0fr147eLYO636OURmQ> <xmx:Rzt6XqSZe4m2uWwEZysYiMOC-1aAQg3hxJWEoHSe4k7ncDI9I_TZ1Q> <xmx:SDt6Xu-roXOUKVaVGrV4vJM57e1yO79MblswI5AKU8GrolwSTVKJEfKvA0U>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B67DCC200A5; Tue, 24 Mar 2020 12:54:31 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 24 Mar 2020 17:54:09 +0100
From: Job Snijders <>
To: Stephen Kent <>,
Content-Type: text/plain
Archived-At: <>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Mar 2020 16:55:00 -0000


On Tue, Mar 24, 2020, at 16:51, Stephen Kent wrote:
> Use of TLS, absent a CA compromise, protects against MITM attacks.

In a perfect world things are perfect? :-)

> The CA compromise you cited (DigiNotar) was serious because of the Web 
> PKI model, in which any trust anchor can issue a cert for any EE. Today, 
> with the use of cert pinning and cert transparency logs, the likelihood 
> of such attacks has very dramatically decreased in the Web PKI environment.

Yeah - I've seen tremendous improvements to Web PKI in the last few years. But still, CT logs are a reactive measure. In some countries operating systems may come with a compromised CA. A recent example:

> Can you provide an example of one of the "crazier things" (relevant to 
> TLS and the Web PKI) hat have happened in the wild, and which are 
> applicable here?

I think there is no shortage of examples where the safety that should've been provided by TLS, was compromised because of a software defects or a misunderstanding in an implementation. This recently hit the news too:

I don't think this thread is not about whether TLS is perfect or not. I think most of us agree it is great we have an improved replacement for rsync in the pipeline. However, RPKI (as I understand it) was designed around being "self-contained" and the promise sort of seemed to be that regardless of the security (or insecurity) of the retrieval mechanism, a RPKI repository can and must be verified.

For the purpose discussion in SIDROPs, I think it is fair (and a necessity) to assume that MITMs are possible regardless of the repository retrieval mechanism in use.

Kind regards,