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

[Stephen Kent <[e-mail]>]

Tim,


Sorry to have not replied sooner.



> 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.
I think an 8-hour cycle is very much overkill, despite the good 
intentions that motivated it.

An RP should detect when a manifest is stale, since the manifest carries 
a next publication date. It's a local matter as to how stale a Manifest 
can be before an RP sounds an alarm. The actions an RP MAY take in the 
face of a stale Manifest are also largely a local matter, as per RFC 
6486. So, I don't think an 8-hour re-pub rate is warranted given these 
local policy aspects of Manifest processing.

Similarly, daily CRL publication strikes me as overkill as well. Yes, 
it's nice to be able to say that IF there were a need to revoke a cert, 
everyone could know about that in 24 hours. BUT, revocations in many 
PKIs are fairly rare, and in the RPKI they seem very infrequent as well, 
right?

I'd suggest a default next update frequency for both CRLs and Manifests 
of 1 week.
This should be shortened if a resource is about to be transferred, or 
there is a planned key rollover, etc. If we adopt 1 week as the default, 
then pushing out
new versions every 3-4 days would be reasonable, IMHO.

These changes would reduce churn by a factor of 10 or so.
> = 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.
I'm not sure I understand the analysis above. In the current scheme, the 
next update times for CRLs and Manifests are signed objects too. yes, an 
RP could learn about an earlier update IF there is no attack that 
prevents timely dissemination of the notification file. But, what 
prevents an attacker from delaying such notifications?

I'll have to think about your TA questions some more before replying.

Steve