@mnot The Internet is always evolving, and Geoff is right that security-by-TLS has beaten security-by-DNSSEC hands down. But then TLS credentials depend on proof-by-DNS, and thus from the security of DNS resolution. If we want to ditch DNSSEC, it would be nice to have some theory on the security of DNS resolution that does not have a circular dependency on the security of TLS.
@jeroen@feld@mnot Dane pretty much means that the TLD managers set the policy. So we would get up to 1400 CA, probably much less because many orgs manage multiple TLDs. Still some competition, but changing CA would require changing name, and that's a big hurdle.
@jeroen@feld@mnot the domain operation depends on the TLD continuing to advertise the name, and neither Dane not PKI will change that. The failure mode of Dane is if the TLD registry somehow hacks the client domain DNS data, so that a hacker (or a state agency) can intercept the domain's traffic. The domain has to "trust" the TLD management, because there is not much they can do if the TLD managers start colluding with attackers.
@jeroen@feld@mnot If a CA is caught playing games, they will be taken out of the trust list of lots of key software and the domains will just get certs from different CA. But if a TLD plays games, the only remedy for existing domain users is to change domain names. That's why many people are uneasy, especially when it comes to ccTLD.
@peterbutler@mhoye
I don't know how they come to "excluding Tesla, 13.3%". If I do the math, the sum for all vendors except Tesla went from 92,206 to 119,467, i.e., +27,261, or +29.6%. The market share of Tesla dropped from 63.7% to 54.0%. It is probably going to drop further if the trend continues.
@mattblaze I am sure it is an optical illusion. The vertical lines, if I measure them, are parallel to the vertical edge. Yet, when I look at the picture, I have the impression that the buildings are wider on top. Any idea why?
Post from @rabble on why he's chosen to use #Nostr and not #ActivityPub and the #Fediverse. He makes some compelling points. Personally I am not too worried about the server admin parts of his argument (I have enough control, even if I don't control the server), but I agree that this isn't ideal:
@enoclue@joebeone RPKI probably helps filtering out bad routes, but it is also introducing its own failure mode. An incorrect RPKI entry, voluntary or not, can create its own outages. See for example:
Question for DNS experts. Do you know of a DNS resolver software that can be configured to use a different IPv6 privacy address for each outgoing DNS query?
@SteveBellovin This is discussed in the thread. The simplest solution is probably to have the server act as a router, and be the sole user of the IPv6 prefix. Maybe using something like prefix delegation.
Recently places like @SIDN (Dutch national operator of .NL) have been claiming that nobody in Europe can deliver their computer needs, and that they are therefore forced to outsource operations to American cloud providers. Meanwhile our own IT industry denies this. Here I delve into what's going on, and how Europe is being Cloud Naïve instead of Cloud Native.
@jornfranke@bert_hubert@SIDN Bert, did you analyze the market incentives there? Suppose OVH or Hetzner come up with their own version of cloud storage, would it sell? Probably only if there is dome kind of standard, as you say. But could such a standard emerge without Amazon and Microsoft? And if it did, how long before "embrace and extend"?
@bert_hubert The silicon valley school of system design emphasizes "build a moat" in order to secure a monopoly. Typically relying on network effects and economies of scale. For the cloud service, what is the moat? It cannot just be individual services like S3, because cheaper copies are doable. Security? Identity? Customer support? It is very hard to compete without understanding that.
"I deleted keys generated by our TV for 5 straight minutes. 5 Minutes of like 200BPM clicking. I restarted. Everything worked again. I laughed so hard I cried. I felt like I'd solved a murder."
@davemark This actually looks like a bug in windows. Anything that causes the OS to fail is a bug. OK, so the TV is creating fake UUIDs each time it does a DHCP request. I don't know why HiSense does it, but it is about the only way to obtain privacy addresses and avoid DHCP tracking, so there are legit usages. Someone did not foresee the scenario and used an O(N) or maybe O(N^2) algorithm to maintain device lists, thus the stall. That's a bug.
Corrected 4/21: UPNP requests, not DHCP
@davemark Thinking of it a bit more, this actually looks like a security bug. Random attacker brings small device to network, starts a loop of DHCP requests from random MAC and with random UUID, watch Windows11 laptops connected to the network start stalling. I don't have the time to repro that, but it is similar to a bunch of low level attacks against OSes.
Corrected 4/21: these were UPNP notifications, not DHCP requests. No random MAC involved.
@ljrk@davemark From the documentation, "network discovery" is set by settings/network settings/advanced network settings/advanced sharing settings. On my PC, this is enabled for "private" networks, so I think it is the default. So the main attack is, some buggy device plugged on a home network. Or, the user did voluntarily open network discovery for public networks, in which case all bets are off.
@raggi@whitequark There was recently a thread in the chat room of QUIC developers -- engineers working on a variety of QUIC implementations, big and small. "Do you implement PMTU discovery". The most interesting answer was something like "we tried, and then we turned it off, because of rare failures that were hard to mitigate, so we just send 1280 bytes packets."