[sidr] The question about https certificates and frequency of mft/crl re-issuance

[Tim Bruijnzeels <[e-mail]>]

Hi all,

I promised to take this to list.

So, as presented today, the volume of updates of MFTs and CRLs in the RIPE NCC repository vs updates of ROAs is about 1000:1. This is a bad signal -to-noise ratio that causes waste of cycles and bandwidth.

= Why this noisy? MITM..
We get this, because we use a 'next update time' of 24 hours, but we actually republish every 8 hours to make sure that we can fix issues before things go stale. In my understanding we need this because of man-in-the-middle attacks involving replay or withhold. And rsync is vulnerable to this (clear text, and no authentication of server). If an RP is being fed old data, they would notice that something is wrong within 24 hours. A longer period seems scary.. If this understanding is wrong I would love to be educated.

= Solved by https?
But assuming this does make sense, I wondered whether RRDP with httpS offers a way out of this. With RRDP a CA signs a certificate with an https URL like: https//my.repository.example.org/notification.xml. We can trust this because it's on a signed certificate. Now, if we can also exclude mitm, because we can trust the httpS certificate, this would allow for a much longer period 'next update time'. And in the meantime the RP would still learn about updates before this, because the notification.xml is checked regularly and would include any changes ahead of this.

= If so, how to handle https TAs?
This is a question for RPs. But trusting all https certificates or all default TAs configured on a system is potentially problematic if the CA assumes that RPs check against mitm. Some of the many TAs preconfigured in browsers have been shown to have issues here.

Then again, RP software could be pre-configured with a smaller set of TAs or even server certificates for know repositories and offer an interface to operators to change this set. Or RPs could accept new certificates for repositories, but require operators to confirm changes. The number of expected repositories isn't great. But there clearly are scaling issues here.

As I stated on the mic. I don't claim to have the answer. But I think it's really worth thinking about ways to reduce the signal-to-noise ratio mentioned.

Tim