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

[Stephen Kent <[e-mail]>]

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:https://www.zdnet.com/article/kazakhstan-government-is-now-intercepting-all-https-traffic/

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:https://www.zdnet.com/article/lets-encrypt-to-revoke-3-million-certificates-on-march-4-due-to-bug/
>
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.

Steve