rjst01

Are you able to share how you evaluated this? Is this based on gut-feeling or is it data-driven?

If you're involved in the hiring process at your org at all, and they ask these type of questions, I'd encourage you to try to as-objectively-as-possible evaluate how much of a signal they actually provide.

Thanks for the suggestion. I'm on iOS but the notification settings look the same.

I already had all but one of the settings you mentioned disabled, along with most of the others. I'll report back in a day or two.

Yes, but once that access is revoked, that is enough to be certain that the attacker can no longer issue certs. With your proposal, I would then have to audit my TXT records and delete only attacker-created records.

(Which in general would be a good practise anyway, because many services do use domain validation processes similar to what you propose)

Of course - but that requires the owner to know they were attacked, know the attacker added a TXT verification, potentially overcome fear of deleting it breaking something unexpected, etc.

> DNS auth would be okish if it was simply tied to a txt entry in the DNS and valid as long as the txt entry is there. Why does LetsEncrypt expire the cert while the acme DNS entry is still there? Which attack vector does this prevent?

An attacker should not gain the ability to persistently issue certificates because they have one-time access to DNS. A non-technical user may not notice that the record has been added.

> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?

Control over a subdomain (or even control over the root-level domain) does not and should not allow certificate issuance for arbitrary subdomains. Consider the case where the root level domain is hosted with a marketing agency that may not follow security best practices. If their web server is compromised, the attacker should not be able to issue certificates for the secure internal web applications hosted on subdomains.

I think the parent commenter would be satisfied if they could authorize their DNS by creating a DNS challenge entry one time, and then continue to renew their certificate as long as that entry still existed.

And I'm sympathetic to the concerns that automating this type of thing is hard - many of the simpler DNS tools - which otherwise more than cover the needs for 90% of users - do not support API control or have other compromises with doing so.

That said, I do think LE's requirements here are reasonable given how dangerous wildcard certs can be.

I had to completely turn off notifications for Instagram because none of the provided settings appear to disable the almost-daily "for you" and "trending" notifications. Now I don't get notified when someone DMs me there, which has lead to me missing important messages.

> Encryption for 30 years ago? Trivially breakable with quantum

I wouldn't be so sure - quantum computers aren't nearly as effective for symmetric algorithms as they are for pre-quantum asymmetric algorithms.

The headline here makes it sound (to me) like Salesforce did the study.

In practice, whether or not this actually works can be very hit-or-miss. We've found several UEFI implementations will not consider a disk bootable if the pMBR doesn't exactly match the spec, which specifies that the 'protective' partition shouldn't be marked as bootable in the MBR partition table.

Meanwhile, other implementations will not consider the disk bootable in BIOS mode if the partition in the pMBR is not marked bootable.

Why? We are running the exact same images that we would be mirroring into and pulling from our private registry if we were doing that, pinned to the sha256sum.

It is a trade-off. For many services I would absolutely agree with you, but for hosting public open-source binaries, well, that really should just work, and there's value in keeping our infrastructure simpler.

> Your case is simply prioritizing work that you would have wanted to complete anyway

It's busy-work that provides no business benefit, but-for our supplier's problems.

> specific outbound IP addresses that they can then whitelist

And then we have an on-going burden of making sure the list is kept up to date. Too risky, IMO.