Look, if no one can summon the energy to respond, Tim has no way to decide on a change.
So the current direction will not change. If you are one of those who were speaking at the mike, please consider typing at a keyboard. —Sandy, speaking as one of the wg co-chairs and nag On Jun 8, 2016, at 10:36 PM, Sandra Murphy <[email protected]> wrote: > Tim’s been waiting very patiently for any response to this. > > The discussion was energetic and lots of people commented during the meeting > and Tim promised to bring it to the list. > > Where it looks like it is dying. Those people who were speaking at this mike > so energetically should be responding. > > —Sandy, speaking as one of the wg co-chairs and nagger > > > On Apr 4, 2016, at 6:51 PM, Tim Bruijnzeels <[email protected]> wrote: > >> 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 >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
