Interesting timing. DNSSEC came up on the NANOG list today -- someone sent out an FYI to a USENIX paper [1] which shows that the law of unintended consequences is still strong and active. In the case of DNSSEC; there is an increased chance of a user being unable to resolve a protected domain -- particularly in APNIC.
[1] https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impact- dnssec-deployment ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Fri, Aug 16, 2013 at 6:25 PM, C. Scott Ananian <[email protected]>wrote: > On Fri, Aug 16, 2013 at 8:17 PM, Tyler Romeo <[email protected]> wrote: > > > With that said, I think the real problem with Wikimedia's security right > > now is a pretty big failure on the part of the operations team to inform > > anybody as to what the hell is going on. Why hasn't the TLS cipher list > > been updated? Why are we still using RC4 even though it's obviously a > > terrible option? Why isn't Wikimedia using DNSSEC, let alone DANE? I'm > sure > > the operations team is doing quite a bit of work, but all of these things > > should be trivial configuration changes, and if they aren't, the > community > > should be told why so we know why these changes haven't been applied yet. > > > > I believe the short answer to your questions is: because Wikipedia lives in > the real world. Some of the trivial changes you describe would make the > site inoperable for large numbers of users. Even switching to HTTPS-only > potentially locks out a billion or so people. > > That said, I'm not part of the operations team either so I can't answer > definitively. I agree that it would probably be useful to have more formal > progress reporting. "Can't disable RC4 in the cipher suite until more than > N% of our readers are using <a set of known good browsers>" for example. > There has been discussion elsewhere on wmf lists about metrics reporting. > Once the blockers were quantified, it would be easier for interested > people to 'count the days' until greater security could be enforced, or to > bring pressure to bear on upstream providers (of the chrome browser, of DNS > root zones, etc) where security fixes are needed. > > Zack: what would probably be useful is to compile your list of suggestions > into a number of specific issues in bugzilla (enable DNS sec, disable RC4, > etc). Some of these probably already exist in bugzilla, they should be > uncovered. A tracking bug or wiki page could collect all the different > bugzilla tickets for anyone who wants the big picture. > --scott > > -- > (http://cscott.net) > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
