jocluteseh

> You are assuming that your client OS/browser DNS resolvers have the pre-shared trust anchors for whichever root zone. That's kind of a big assumption.

First: There are two arguments to be had. One is the server side, and one is the browser side. The server is going to know about the key problem if it happens. The client side browser can know, if the client is using plugins like this one:

https://www.dnssec-validator.cz/

Second: Here is the root key: https://www.iana.org/dnssec/files

> Fair enough.. but if you're talking to a MITM anyway, would you agree that it's game over?

Don't think: 1/10,000 chance. Think: 1/1,000,000,000,000,000,000,000 chance.

You are much more likely to die by getting run over by an airplane while walking down the road while also holding a Dalmatian over your head, than to have your DNSSEC signed domain redirected.

The edge case that's being argued about NSA taking over DNSSEC is rather over done.

However, if the argument is denial of requests, so as to block traffic, DNSSEC or not matters not - so the argument again -- is not about DNSSEC as a specific service or architecture.

I'll try to post a comment, but my IP address may be rate limited -- I keep getting "You are posting too fast" errors.

In any case, you've made my case for me much better than I could have made it myself. The problem with the 'redirect DNS' argument is that -- it seems -- most people misunderstand that in order to redirect a DNSSEC signed domain, you need to control the 'root' key AND re-sign every domain under that key.

So, can it be done? Yes.

Is it likely to happen? No.

I would argue that the re-direct DNSSEC argument is nearly vanishingly small. But it can't be claimed to be zero.

Done... enjoy... or not, but just make sure the beer is cold.

https://gist.github.com/anonymous/3f36dfeb3297e184417b#file-...

1.a.1 I think this is your main fault. You are assuming that end-to-end encrypted message content is equatable to 'insecure' SMTP. The clear text or encrypted content of an email message has nothing to do with validating that an email account belongs to a domain and is valid.

SPF validates that the email account holder is valid.

DKIM signs the message and provides a body hash which is validated against the public key in DNS.

DMARC allows the domain owner to say that the message should trashed or passed.

And DNSSEC allows the DNS root to say that the sending domain is the sending domain.

So -- I repeat -- with SPF, DKIM, DMARC, and DNSSEC email validated CA certificates are quite secure.

And, yet, you are unwilling to admit this...

I suggest you read the DKIM RFCs, particularly RFC5585

"2.3. Establishing Message Validity

Though man-in-the-middle attacks are historically rare in email, it is nevertheless theoretically possible for a message to be modified during transit. An interesting side effect of the cryptographic method used by DKIM is that it is possible to be certain that a signed message (or, if l= is used, the signed portion of a message) has not been modified between the time of signing and the time of verifying. If it has been changed in any way, then the message will not be verified successfully with DKIM."

Fixed formatting a little here: http://shortText.com/6308c7af

1. Why? An unqualified blanket statement does not prove anything. SPF, DKIM, DMARC provide strong cryptographical ties to a specific, real, and verified account holder. DNSSEC provides domain level certification. So, with all four items, there is a very strong assurance level of the validity of the email account holder. Do you honestly disagree?

2. Can DNSSEC be re-directed to incorrect public keys? Sure. But DNS can be pointed anywhere anyway. DNSSEC does no extra damage. And exploitation of DNSSEC enabled domain records is very easily discoverable by the domain holder, since the public key will no longer match the domain's private key... which is still very much in the domain owner's control.

3. Much of cryptography dates to the 1950s. This '90s cryptography stuff is pure nonsense.

4. Only if you don't value the hard work by many smart people over a long time.

5. OK. Denial of service is a bad thing. If you have a worldwide network, you are going to have denial of service. Mitigation is possible... maybe instead of throwing out other people's work, some resources could be used to improve what's already out there... ah... but then back #4.

6. Yes it is.

7. Revealing hostnames is only a problem if a domain is seeking to hide hosts. So, this particular issue is domain level dependent -- why not let a domain owner speak for him/her self?

8. Again with the 'old' is bad 'new' is better? Got anything else?

9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why.

However, for a small domain, DNSSEC is terrific.