[giovannibajo1]

The only problem with DANE is that it doesn't protect from NSA. You are simply moving trust from CAs to your TLD owner. Whoever controls your TLD (and whoever can subpoena them) is able to change your zone file without you realizing it.

[ahf]

Yeah, that's true; DANE does not add anything to the encryption of the protocol itself.

The point of this is to, hopefully, slowly get people to start actually verifying certificates instead of just randomly assuming that they are secure.

[ptrf]

Using DANE in tandem with DNSSEC ensures that such changes wouldn't go unnoticed.

[giovannibajo1]

Why do you think so? Let's assume I have complete control over a TLD zone file (.com), into which you inserted the DS records of your DNSSEC-signed domain (example.com). Let's say my goal is to MITM users connecting to https://www.example.com relying on DANE for trust of TLS certs.

I surely cannot modify the records in your signed zone because I don't have your KSK/ZSK private keys. What I can do instead is preparing a duplicate of your zone, signed with a freshly-generated KSK/ZSK pair; in that zone, I will change only the DANE records (or also the A records, depending on the kind of MITM attack I need to mount), and I will sign everything with my new keys. Then, I start MITM'ing my target so that:

* DS records replies for example.com contain the DS record for my own KSK/ZSK keys.

* NS records replies for example.com direct to my own nameserver (or even simply MITM the glue records, depending on the nameserver setup).

* My nameserver will reply as authoritative for example.com, and will serve the modified zone, which will be fully DNSSEC validated.