I remember reading some people can perceive some near IR, but mostly that near-IR LEDs actually leak some red themselves due to imperfections in manufacturing or something?
You could strobe at some multiple of the sensor frame rate as long as your strobes are continuous through the integration period of the sensor and the lighting fades very quickly. This probably wouldn't work with incandescents but people strobe LEDs a lot to boost the instantaneous illumination without going past the continuous power rating in the datasheet.
You mean do strobe, strobe, strobe, strobe, pause, pause, pause, pause? I bet that's at least as bad as holding the source on for the first four intervals and then off for the latter four intervals.
In any case, if you actually have a scene bright for 1/24th of a second and then dark for 1/24th of a second, repeating, you're well within photosensitive epilepsy range. Don't do that to your actors unless you've discussed it with them and with your insurance company first.
You're not providing any explanation for why I wouldn't trust OP on DNSSEC. And the FUD is pretty reasonable if you've had a lot of experience setting up certificate chains, because the chain of trust can fail for a lot of reasons that have nothing to do with your certificate and are sometimes outside of your control. It would really suck to turn it on and have some 3rd-party provider not implement a feature you're relying on for your DNSSEC implementation and then suddenly it doesn't work and nobody can resolve your website anymore. I've had a lot of wonky experiences with different features in EG X.509 that I've come to really mistrust CA-based systems that I'm not in control of. When you get down to interoperability between different software implementations it gets even rougher.
Which is exactly what happened to Slack, and took them offline for most of a business day for a huge fraction of their customers. This is such a big problem that there's actually a subsidiary DNSSEC protocol (DNSSEC NTA's) that addresses it: tactically disabling DNSSEC at major resolvers for the inevitable cases where something breaks.
As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it.
It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.
DNS underlies domain authority and the validity of every connection to every domain name ultimately traces back to DNS records. The amount of infra needed to shore up HTTPS is huge and thus SSH and other protocols rely on trust-on-first-use (unless you manually hard-code public keys yourself - which doesn't happen). DNS offers a standard, delegable PKI that is available to all clients regardless of the transport protocol.
With DNSSEC, a host with control over a domain's DNS records could use that to issue verifiable public keys without having to contact a third party.
I ran into this while working on decentralized web technologies and building a parallel to WebPKI just wasn't feasible. Whereas we could totally feed clients DNSSEC validated certs, but it wasn't supported.
Thanks for the explanation. It seems like there are two cases here:
1. Things that use TLS and hence the WebPKI
2. Other things.
None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.
That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
> None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.
It would benefit the likes of Wikileaks. You could do all the crypto in your basement with an HSM without involving anyone else.
> That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
But do they? That requires adding support for another protocol.
I would like to live in a world where I don't have to copy/paste SSH keys from an AWS console just to have the piece-of-mind that my SSH connection hasn't been hijacked.
In practice, fleet operators run their own PKIs for SSH, so tying them to the DNSSEC PKI is a strict step backwards for SSH security.
There may be other applications where a global public PKI makes sense; presumably those applications will be characterized by the need to make frequent introductions between unrelated parties, which is distinctly not an attribute of the SSH problem.
And for everyone else that just wants to connect to an SSH session without having to setup PKI themselves? Tying that to the records used to find the domain seems like the obvious place to put that information to me!
DNSSEC lets you delegate a subtree in the namespace to a given public key. You can hardcode your DNSSEC signing key for clients too.
Don't get me started on how badly VPN PKI is handled....
Yes, modern fleetwide SSH PKIs all do this; what you're describing is table stakes and doesn't involve anybody delegating any part of their security to a global PKI run by other organizations.
The WebPKI and DNSSEC run global PKIs because they routinely introduce untrusting strangers to each other. That's precisely not the SSH problem. Anything you do to bring up a new physical (or virtual) involves installing trust anchors on it; if you're in that position already, it actually harms security to have it trust a global public PKI.
The arguments for things like SSHFP and SSH-via-DNSSEC are really telling. It's like arguing that code signing certificates should be in the DNS PKI.
We also have thousands of devices accessible over SSH and we maintain our own PKI for this purpose as well. We also use mTLS with a private CA and chain of trust, for what it's worth.
No, we run a fleet with thousands of physicals and hundreds of thousands of virtuals, of course we don't hardcode keys in our SSH configuration. Like presumably every other large fleet operator, we solve this problem with an internal SSH CA.
Further, I haven't "moved on to another argument". Can you answer the question I just asked? If I have an existing internal PKI for my fleet, what security value is a trust relationship with DNSSEC adding? Please try to be specific, because I'm having trouble coming up with any value at all.
Actually, does it? Yes, the obvious upside when I type in slack.com instead of 123.45.56.67 is very good. Does this same upside apply to addresses I don't type in? What's actually the advantage of addressing one of foobarcorp's infinitude of servers uasing the string "123-45-57-78.slp05.mus.foobar.com" instead of "123.45.57.78"? It seems to just waste bytes. And most communication is of the latter sort - an app talking to its own servers managed by the same company.
BGP can be hijacked. Anycast IPs exist. Rolling out a new release when one of your IPs is unavailable could be a severe challenge. SVC records are actually kinda neat.
All of that's a problem with DNS too, even updating the IP. You could still use it to get the initial entry point if you wanted. But when you serve a webpage with an automatically generated pointer to image3.yourdomain, the only reason not to make that an IP is HTTPS, and LE just started issuing IP address certificates. Think about it - it saves a few round trips.
Huh? They really don't. It's actually kind of unfortunate that browsers don't have uniform policies about what certificates they accept, but for obvious reasons each browser wants to make their own decision.
They do have uniform policies, those policies come from the aforementioned CA/Browser Forum, which has been issuing its Baseline Requirements for over a decade.
Also of note is they were responsible for medical debt cases, which are particularly difficult for people to resolve because of the shared responsibility between the patient and the insurer, which allows the insurer to deflect responsibility until the bill ends up in collections.
If it's almost free, then even electrically cracking molecules to make hydrocarbons and ammonia compounds is cost-competitive if you can quickly start and stop production, which would be really interesting. Those processes don't have to be very energy efficient if the capital and operating costs are relatively low. That last sentence does a lot of work though.
I think we should solve the "It's cloudy sometimes" problem with state built, extreme oversupply. Also giant solar farms in the southwest and large HVDC power lines to send that everywhere.
There's zero reason why "We make more power than we use most of the time" ever has to be a "problem". I think we should have so much unused power that it makes sense to suck CO2 out of the air to make fuel and chemical feedstocks. Air capture at that scale would be an insane engineering and manufacturing problem though.
You probably shouldn't vote for me though. I have dumber ideas too. But the "Lets do Solarpunk for real" one is probably not harmful to anyone. Except for a bunch of rich families in Texas.
Terraform is working on that - burstable synthetic methane generation using cheap catalysts that you can afford to idle, only generating methane when electricity is cheap.
The burden is on you to explain why the US should do things the way other countries do. What's better for everyone about that? Why should we change our notion of justice to make you feel better about it?
What proportion of road deaths are due to people running red lights versus just driving too fast for conditions, or being impaired at the wheel, or any number of things that these cameras don't enforce?
reply