CAA is NOT checked by browsers, the BRs do not say browsers should check CAA, and indeed it is specifically NOT designed to be checked by RPs at all. CAA tells the Issuers (Certificate Authorities) whether the name owner authorises them to issue at a moment in time.
If you think "that seems useless" it's probably because you completely misunderstood the security model it's written for. We don't want untrustworthy or incompetent CAs at all, this is not a guard against those. This is a guard against trustworthy, competent CAs that you've got your own reasons to disallow for your specific names.
Example: Facebook for years had a single preferred CA and their contract with that CA said everything gets signed off by the certificates team. After Let's Encrypt came on the scene a subcontractor developing example.facebook.com needed HTTPS, didn't read all the paperwork from Facebook and just got a cert from Let's Encrypt. Facebook security freaked out because their team hadn't authorised this weird new certificate. Let's Encrypt did nothing wrong, but it looked exactly like an attack. CAA lets Facebook tell every CA except the one that knows about their internal policy, "Thanks, but no thanks". Let's Encrypt would have checked CAA and told the subcontractor "Sorry, no, policy forbids, check CAA" and when they went to Facebook to ask why they'd have got an earful for not obeying policy.
I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.
One way this is true is that people won't use security if it isn't usable or easy to use. For almost two decades we had CA workflows that sucked. Certificate use has spiked in the last couple of years. Why? Witness the outstanding work by LetsEncrypt which is now allowing Chrome to flag insecure login forms.
Other examples; DDoS defense as a service, facial recognition that unlocks your phone every time you pick it up, cars that lock when driving, and fobs that make passwords almost irrelevant.
Good security and making someone's job easier are one and the same.
Even the "corporate policies" is a security thing, not "making someone's job easier". Presumably Facebook handles their certificates carefully: if any engineer could obtain certificates the odds that they would and that the certificates would be passed around in email attachments is 100%.
Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, auditable log of every certificate officially issued could can be used to validate certs, Chrome enforces this with new EV certs and Symantec certs.
Conceptually I don’t see any major problem with using CAA for this purpose though, at least for your own internal PKI. The only potential issue is that if you change your CAA record your issued certs would break, so there’s an availability attack.
I just found a reference to another standard called DANE that’s supposed to do this, but I don’t know anything about it.
Granted having your own home-grown authentication & identity management "salad", or a very complex system that never addressed identity/authenticity, ... then replacing this with PKI will force you to deal with a lot of technical debt. But don't blame PKI for it.
Blaming PKI has become rampant. Those that don't know can't dispute the nonsense and those that do know may have an agenda (snake oil vendors).
Hating on PKI has become like a bad habit in IoT (vendors see an opportunity to sell trash to an uninformed and ignorant audience). Be careful especially in IoT: There are a lot of snake oil proposals which promise to replace PKI here ... you should run as fast whenever you see these "proprietary, patent-pending, post-quantum-proof, blockchain solutions !! (the correct response to these vendors is: "BEGONE MAGICIAN!").
PKI isn't easy but neither is email, Kubernetes! It's as simply as it can be given the circumstance and job it has to solve. And PKI is essential knowledge as much as Latin is required for medicine.
Perhaps as knowledgeable engineers they can understand accidental complexity when they see it.
However, the systems that people build on top of SMTP (often to address shortcomings in SMTP being too simple) can often be Lovecraftian horrors.
Fortunately, as someone pointed out up-thread, the demand for new PKI being generated not just for SSL by things like Let's Encrypt but also by things like device-aware trust is helping encourage a trend in making it easier to do it correctly and harder to do it wrong. Not quite there yet, but showing signs of improvement.
My complaints with PKI aren't technical difficulty but administrative and bureaucratic. Consider; The NSA issues an NSL for all the root keys to YourCA Inc. Now what?
We would flee PKI like rats from a sinking ship if the capacity for a government to obtain any CAs private keys was written into code. But because its written into policy we simply ignore it.
Usually when people complain about PKI being too complex, they're complaining about the opacity of the implementations. Certificates just stop working, and you don't get anything, and there's nowhere to look to figure out why unless you're really an expert on the topic.
Those are kind of two different things. Aircraft work. Brains work. CPUs work. Many things work and are still complex.
Also you've mentioned in the section “Naming things” that DN is deprecated, strictly speaking it's not. The Subject field is deprecated when browser matches certificate with domain, DN is still perfectly valid and Subject field MUST contain a proper DN as stated in https://tools.ietf.org/html/rfc5280#section-4.1.2.6.
The convention used to be that the CN field must match the DNS name of the server in a server TLS certificate, but this feature is indeed deprecated and the DNS name extension should be used instead.
Anyone able to shed some light on what happened there to me?
You were requiring TLSv1.2 but some other remote mail systems didn't support it and were unable to fallback and, as a result, couldn't negotiate a secure connection.
Or did I miss something?
If it was TLS 1.2, disable 1.0/1.1 again and check you still have that cipher available.
It's far better to force them to upgrade than to allow them to force you to be insecure.
They are supposed to whitelist financial addresses (such as banking details) but would you trust that to be happening?
http://www.robinhowlett.com/blog/2016/01/05/everything-you-e...
Disclaimer: I write blog posts to figure out if I understand something correctly and appreciate any and all feedback, negative or positive.
Edit: actually this is way more in depth than is needed for k8s. But, I think that's a good target market for a book you can sell like candy for $25.
The closest I know of are the Julia Evans' zines, but I think you meant something different.
Not sure about 20 pages or so, but there's a whole variety of short tech books. O'Reilly had their "pocket reference" series, some of which are less than 100 pages.
