Office 365 to support DANE and DNSSEC

OK, I looked. Here's my response. Call it "Against Against DNSSEC, and For DNSSEC".

> DNSSEC is Unnecessary

Quite the contrary. If nothing else, it's the only technology we have with proof of non-existence. That's very valuable.

> DNSSEC is a Government-Controlled PKI

If you use QName minimization then it's really hard for the government to abuse those keys: they'll get caught unless they MITM you all the time, and to do that they need to know exactly who to MITM all the time. It was always important to use QName minimization anyways -- essential, I'd say.

Also, anyone can run their own roots, and you can bet that other governments (e.g., Russia's) have plans to run their own if need be.

WebPKI is no-PKI. Whether it's WebPKI or real-PKI, CAs can be subverted by the governments that have jurisdictions over them. CT is not yet clearly a good enough answer (it's post-hoc, for one), but if it is then guess what: CT would also work for DNSSEC.

I.e., everything is "government-controlled", and no technology beats the rubber hose. Thus "DNSSEC is government-controlled PKI" is grossly misinformed in the best case, or willful FUD in the worst case.

> Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.

As if the U.S. could not get ICANN to change the .ly delegation if it came to it.

> DNSSEC is Cryptographically Weak

DNSSEC supports new algorithms.

> No cryptosystem created in 2015 would share DNSSEC’s design.

WebPKI has the same problems because... PKI has this problem... because many protocols have this problem, that you have to support old algorithms for a while. TLS has this problem too.

BTW, PKCS#1.5 is especially bad for encryption, but not so much for signatures. See https://cryptosense.com/blog/why-pkcs1v1-5-signature-should-... which argues that PKCS#1.5 should be replaced for signatures, but clearly the situation for signatures is infinitely less bad than for encryption.

> DNSSEC is Expensive To Adopt

> [DNSSEC] adds two new failure cases: the requestor could be (but probably isn’t) under attack, or everything is fine with the name except that its configuration has expired.

TLS (WebPKI) has that too. Also, just because a zone is signed doesn't mean that an application making queries against it needs to validate signatures -- you can have DNS-using apps that are DNSSEC-oblivious. DNSSEC doesn't make using DNS worse in apps where validating DNSSEC signatures is not useful. DNSSEC enables new / improved applications however.

And... DANE for SMTP adoption, and Viktor's yeoman's work on that are making it less expensive to adopt and run DNSSEC by causing more effort to be put into making it effortless.

By poo-pooing DNSSEC you might cause some people to shy away and thus you are part of the reason DNSSEC is hard to adopt.

> A lot of code will need to be rewritten to make DNSSEC workable.

No, a lot of code will need to be modified to take advantage of DNSSEC. That's a huge difference.

Yes, browsers don't bother with DNSSEC. That's fine. Eventually they might (I predict will).

> DNSSEC is Expensive To Deploy

See above.

> DNSSEC is Unsafe > ... > But DNSSEC is designed for offline signers; it doesn’t encrypt on the fly.

First off, you meant sign, not encrypt. Secondly, that's flat out wrong. A number of large providers sign records on the fly. PowerDNS supports it. It's not hard. In fact, it's easier than offline signing.

Which makes this:

> Authenticated denial. Offline signers. Secret hostnames. Pick two.

wrong.

> DNSSEC is Architecturally Unsound

This section is so wrong I don't know where to start. You essentially imply that end-to-end security shouldn't rely on trusted third-parties:

> A casual look at the last 20 years of security history backs this up: effective security is almost invariably application-level and receives no real support from the network itself.

Oh? So no WebPKI either then. No DNS for that matter. Or routers. Just IP-over-pigeons, I guess. (I can snark too. It's not very nice though. I'm starting to snark because the "Against DNSSEC" arguments are so trivially bad.)

Finally we come to the crux:

> DNSSEC doesn’t have to happen. Don’t support it.

All I see is that you don't want it to happen, so you take advantage of your abrasive personality and sheepish people to spread ill-founded, snarky FUD against it.

You don't even address the arguments for DNSSEC. You just attack [with dull blades]. One would think that addressing the arguments for DNSSEC would be part of the argument against it -- it would be the polite and professional thing to do. I'm prepared for DNSSEC not to be the answer, but I'm not prepared to accept your say-so on the basis of "Against DNSSEC".

It's funny though, you don't make the one argument against DNSSEC that for a long time has been most well-founded: the DDoS threat from response magnification. Fortunately the Internet is moving to DoH and DoT, which means using TCP, which means making the DDoS problem go away. Also DNS cookies are getting more support. Also, modern pre-post-quantum signature algorithms have smaller signatures anyways, which further makes DNSSEC less useful for DDoS.

I'm not saying there's no DDoS issue, just that it's getting mitigated or fixed, and it's not even an argument you made in Against DNSSEC.

In conclusion: "Against DNSSEC" is wrong and weak tea.

"For DNSSEC" certainly needs to be stated though. I don't want to just tear down your article. Briefly:

  - DNSSEC is the *only* properly name-
    constrained PKI we have;
  - DNSSEC does provide usable security
    against misbehaved zones (CAs) when
    resolvers apply QName minimization
    (see above);
  - CT could be applied to DNSSEC if QName
    minimization were insufficient;
  - no certificate tax (fortunately Let's
    Encrypt has made that less of an
    issue anyways, but still, see points
    about name constraints);
  - DNSSEC enables DANE;
  - DANE enables better and somewhat more
    optimized authentication because of a)
    happening in DNS, b) having authenticated
    denial of existence.

Note that we could build a different properly name-constrained PKI out of DNS but without DNSSEC: just make all the registries/registrars CAs and have their trust anchors be name-constrained even if the certificates they issue still can't be name-constrained for whatever reason. This would be good, really good, if we have to stick to PKIX (which I don't mind), but it wouldn't be as good as DNSSEC due to the lack of authenticated denial of existence. Note that you'd still need to use QName minimization because you probably would (correctly) worry about government (and other) subversion of CAs, and you should want to use QName minimization to make it harder for any would-be MITM to decide when to get in the middle.