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

[Francisco Javier Moreno Arana <[e-mail]>]

Hi there,

We had the same discussion (FORT validator dev team) a few weeks ago, since the RFCs don't clarify the subject. Gladly, after reading this thread, we can say that FORT is currently rejecting those CRLs.

We've noticed the RIPE expired CRL and ~70k prefixes were rejected at that moment.

Regards,
Francisco Moreno
________________________________
De: Sidrops <[e-mail]> en nombre de Job Snijders <[e-mail]>
Enviado: lunes, 24 de febrero de 2020 03:15 p. m.
Para: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Asunto: Re: [Sidrops] what to do when the CRL is hosed?

To reply myself:

In case the CRL expired, or is otherwise somehow invalid; and the cache
validator continues to consider the entire validation tree to be valid
for some purpose, the validator is vulnerable to replay attacks because
the use of unencrypted transport such as rsync (which supported in all
validators, by mandate) give no support to trust anything anymore.  I
think ignoring the CRLs state goes against the entire RPKI trust-model
mindset.

A cache validator MUST consider the certificate have been appeared on
the Certificate Revocation List (CRL) issued by the CA represented by
certificate if the CRL is expired.

While one can argue in different contexts of the application of X509
technology different (more forgiving) policies can apply; in the use
case of RPKI I think we cannot tolerate anything less than to assume the
CA has failed when the CRL is inaccessible or expired. And those running
CA's will want to take careful note of this critical operational aspect.

Cache validator implementations which didn't stop parsing RIPE NCC's
tree today, should be aware they are have a security issue and consider
how to upgrade their validation strategy. I think OpenBSD's rpki-client
was the only one to get it right today.

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

Kind regards,

Job


On Mon, Feb 24, 2020 at 03:15:32PM +0000, Job Snijders wrote:
> Hi group,
>
> It seems we need guidance and consensus on what to do when the CRL is
> hosed in some way or shape. We have two implementation discrepancies pop
> up recently:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNLnetLabs%2Froutinator%2Fissues%2F274&amp;data=02%7C01%7Cfjarana%40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637181757516231674&amp;sdata=M%2BMTjX2M%2BYYM3bsSr%2F%2BgonBy6IKSAqaGU%2F4J%2BqlnZ%2BU%3D&amp;reserved=0
> RIPE NCC's top level CRL expired this weekend
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fsupport%2Fservice-announcements%2Frpki-infrastructure-issues&amp;data=02%7C01%7Cfjarana%40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637181757516241663&amp;sdata=s3%2F6i%2BhO4bnqncsSj56ZpXDsulvgWUYA13Nm5%2BmnQiM%3D&amp;reserved=0)
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nlnetlabs.nl%2Fpipermail%2Frpki%2F2019-December%2F000109.html&amp;data=02%7C01%7Cfjarana%40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637181757516241663&amp;sdata=8AHf2i8DNdTjlU6TnGkbnkXK%2BLyIP%2FN3bnr0GlSZ%2B3E%3D&amp;reserved=0
>
> OpenBSD's rpki-client uses the x509 certificate validation functions
> that come from libressl, which doesn't have a button to turn off only CRL
> timestamp verification. I was told that some nasty code would be
> required to work around that, so one can argue that rolling things by
> hand in X509 handling rarely is a great idea.
>
> One could also argue that a softer landing is needed, unavailability of
> the CRL should mean that only the CRL itself is not available and
> proceed to validate the tree without the revocation list. I can see how
> that is helpful in some circumstances.
>
> So, what to do? Whatever it is, ideally all validators follow a similar
> process.
>
> Kind regards,
>
> Job

_______________________________________________
Sidrops mailing list
[e-mail]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Cfjarana%40nic.mx%7C18b6558503814064281c08d7b96eb91c%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637181757516241663&amp;sdata=X8IkntXgxnt345fIIKgQEBc%2FpGuLzjtyiwa59Bf2VMM%3D&amp;reserved=0

Este mensaje contiene informaci?n confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor elim?nalo, ya que difundir, revelar, copiar o tomar cualquier acci?n basada en el contenido est? estrictamente prohibido. Network Information Center, S.A. de C.V., ubicado en Ave. Eugenio Garza Sada 427 L4-6 Col. Altavista, Monterrey, M?xico, C.P. 64840 recaba tus datos personales necesarios para: la prestaci?n, estudio, an?lisis y mejora del servicio, la realizaci?n de comunicaciones y notificaciones; la transferencia y publicaci?n en los casos aplicables; el cumplimiento de la relaci?n existente; as? como para la prevenci?n o denuncia en la comisi?n de il?citos. Si eres colaborador o candidato a colaborador de NIC M?xico, tus datos ser?n utilizados para: la creaci?n y administraci?n de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realizaci?n de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gesti?n y administraci?n de servicios de pago y/o n?mina; as? como para contacto y/o notificaciones. Si participas en promociones o en estudios podr?s dejar de participar. Para mayor informaci?n revisa el Aviso de Privacidad<http://www.nic.mx/es/NicMx.AvisosDePrivacidad>.


This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center, S.A. de C.V., located on Av. Eugenio Garza Sada 427 L4-6, Col. Altavista, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events. If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note<http://www.nic.mx/es/NicMx.AvisosDePrivacidad>.