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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
