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

Stephen Kent <> Thu, 26 March 2020 14:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 343443A0949 for <>; Thu, 26 Mar 2020 07:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.562
X-Spam-Status: No, score=-3.562 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YckKAsjykEwA for <>; Thu, 26 Mar 2020 07:57:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E69253A0C3D for <>; Thu, 26 Mar 2020 07:57:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a2048; t=1585234635; bh=PDTNB4ESNjpijlyUg5T6ly507PM30Fz/0r2yqj4ctN0=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=GKOyO/d90v1pEGQLrxK3i/lB7Zq8cAN8vnzxn3uHD3NaIMq8/Lokz1+FLz3/HEkN35Uux1z5+L9wCQKo/Vd/nZH7vZYGxJ9qwlLXAlGEx7Fw2IxnrUqcEFa+KzElm4LqceHtP73d/t1oAmO8z62buWfwahF2Uj0JOC4lUsEFoaqn4HFo6Xms8H1iy84qifZqwAik0YbeWi0f6ydELWt7BKqvpoby29oqvRCq8nMZjGTqY02EVbwZzUGW9JaH5t0S2K/OFIDJ+s//tBBxQKnhhLrLhH+zITj+AC50PDHtlBcnkqtKet/7D+Y8uXDhgKEZ7o/IH+DGzn18YiMAoGClWw==
X-YMail-OSG: 6CIsCI0VM1kjVQ9lo.NRUkiGrvvBNHbwwRyUZ7ORglthTXUEPs9owMwC1AvUEYN JW5HeNinDp1jlF.bs6IqLlQLDXvK1LQ1RsXIZfw1tZ8z5Xg.TS64sOeM5BWxRrrdx6dYgiMflKwu zVY8SRf5UIVT27GnzeHgMjhE7v0uKtTr.1X0ZNy1OhXMOjRHmBsteb2utVLOZuKNhUG5yfdbc0Fi dYhM8BAh3tKYMt_rz.DPBV3aKhNLG2wsQMLOQk6w2KMif2hboOpHYo8_1WFDBcHNYalmEpAp5AVn FeCih8nNUaYJzeHsl1NihfltF.f5KtMfSYwabpJ5CqRZNo8QGMwQ6qbuD4ibCBns1e0alYFJ6chT ..WrDDC7S_O_zOPa4135ZPxY67V2TG_16WtQP1ubexw3bnptXU933T7qNO_TEbVIjjmSTOEQc0P0 zwiX5BHcqrVJtyTdZYua3h9Zep9JHvL8d7VQW4yUDFmb_F8wKkVE52qKa2i.pNsS3aqHmBIA5UDb UyyXaFfmcTDu47fupqFksR1lP84qEuVLiv_CcCR8yVltMEiabExHy9S81_hBYkbMQy0SkFIyKm6A vU9FtNDBzm.w0M.LXFSyZklFB1DuzJcQ3KxkaMmGNWQwEQVqsUl.5dLJFM98BR8oAQ04fnGWYVYO 0hm3.tvGskuqayvTabK62hee3w7DbXHI2Sa84wG5n8d8lAcwu2hqT1WN31kCImC1rmQeAqEZvSrU F8KWtzEXKbeOM6PLciX3tggbVuKimEt7VyqxKujWuQZZLbwp5QU8PEt5_ENjCp6DJ4OBcNrw14QS slDpyS7h_TNJabV0oqQTG5CWdiVGmriLAlrq2EffrerYBRo3ZluvZP_hA7zteqHK6CcDQf_eXQRi 7ZXwjHdvMaMEtQMtnNE4wT_JFjakrSAMwV4_r9wK1O94OAe2_qckhKr8M8S3Jdk93G5SABgwPZ32 GHt5mJOfSwZDiVOOblHJZDnXo0ofdXoAhyLsxjBC8ZB2.Bqc2CMicBTWNes8EggM7yXJlYpNP.wD stdKxlppkRpzbfIYgXQBSDDROC5duuF.LfFZTvna3Yv0tr_ZuEjbLMk0RzqtNiVWdfKJiD8sgapH MknuFPDRsZiEEe2qoQrsw1N_24p7m0mI3hZStOYR7_uWuFggPIFDgQVAAwdrbN6dfq063nIO1ac. lgLHTDV.ljWbTQwGVTTApqWSkpnlBACxCbQooCwQu5b2xC7qiBlPgTw6rfC9pbAkZsDhp2O.48aM adUpWHIyyH_3Vyxi4Fi0fjkW7phcuj3NtAdbLjBzYsyEqdNoEqf0xn52oatbeGMSX_.IQQnqybPS 3iWd_cxxKBHTZ3.i0vWtMUnsKtuqpBCOmNIcWUfqQycLBS69LaL1sKj4qY3TP4jRe4iVUMnod3ML 2CrhDGY0pmPvWwDWyQ.ekjXAq7cqYrmpakhN7QD7DOtc6Y20Ib2hAvww0MEG.Ux5ia8M-
Received: from by with HTTP; Thu, 26 Mar 2020 14:57:15 +0000
Received: by (Oath Hermes SMTP Server) with ESMTPA ID 77acc748d2d84cd880057f103eb5269c; Thu, 26 Mar 2020 14:57:12 +0000 (UTC)
From: Stephen Kent <>
To: Job Snijders <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
Date: Thu, 26 Mar 2020 10:57:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------4F4B0A6EB0ACA061752E9B8F"
Content-Language: en-US
X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242)
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: Thu, 26 Mar 2020 14:57:43 -0000

On 3/24/20 12:54 PM, Job Snijders wrote:
> Kent,
BTW, my first name is Steve.
> 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? :-)
Those of us who pose as security professionals distinguish between the 
security offered by a correct implementation of a protocol and 
associated crypto, vs.  buggy implementations, poor choice of crypto 
algs, etc.  If you are concerned about the security quality of a TLS 
implementation, then you should be _very_ concerned about the quality of 
the RPKI RP software, based on what we have been hearing!
>> 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:

CT logs also are designed to deter mis-issuance by trust anchors, and 
facilitate remediation when mis-issuance is detected.  In that respect 
they seem to have been effective. Deterence is not reactive. (It's a 
pity that the authors of the CT docs have done a poor job of clearly 
explaining the purposes of the system, but ....)

If you operate in a country where the government can tampoer with the 
version of the OS you use, then none of the security measures we can 
provide via the RPKI will prevent a wide range of attacks on the RPKI 
data retrieved or published by the ISPs in that country. So, that seems 
to be a red-herring in the context of this discussion.

The ZDnet article your cite is analogous to the OS issue; the local 
government could act as a MITM for published and downloaded RPKI data. 
So, for downloaded data the local ISPs could be denied access to current 
RPKI data, or receive only partial RPKI data, which hurts them and their 
customers. For uploaded data, other ISPs could see only partial or old 
RPKI data from the affected, local ISPs. In that case the principal 
effect would seem to be to disadvantage the local ISPs and their 
customers.  So, again, if your local government is allowed to mess with 
you as an ISP, you're screwed, but their ability to adversely affect 
origin authentication info for other ISPs is ??

>> 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:
not a great example, IMHO. The CA back end bug, if not quickly detected 
and remedied, would have caused web sites to not have up-to-date certs, 
which would have resulted in warnings to users (via their browsers). 
Again, this is not a TLS issue, per se, and it did not undermine the 
security afforded by TLS; it potentially caused some level of DoS for 
the affected servers, but DoS protection is NOT a security feature if TLS.
> 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.

Well, as one of the principle architects of the RPKI, I can tell you 
that it was designed with the "principle of least privilege" as a major 
security feature.  In the RPKI context this

     - limits the damage than any individual ISP can inflict as a result 
of local errors in generating certs and ROAs, whether due to software 
bugs, operator error, or local government influence

     - limits the damage that can occur if a repository is attacked

It also was intended to be independent of the Web PKI and its trust 
model. Using RRDP with certs issued by Web PKI trust anchors violates 
the last goal, but the effect seems to be equivalent to attacks on a 
repository. MFTs were designed (again, I was helped defined the concept 
of Manifests) to deal with active attacks on pub point data, 
irrespective of the mechanisms used to distribute that data.

So, I think discussing MITM attacks is a distraction, unless we have 
examples of how such attacks can affect RPs in ways different from 
attacks on repositories. Maybe re-reading RFC 8211 would be useful, as 
it tries to analyze a range of possible "adverse actions"  by CAs or 
repository managers in the RPKI context, and discusses how RPKI 
mechanisms are intended to detect/counter these actions.