Most active commenters
  • teddyh(11)
  • tptacek(10)

←back to thread

246 points nh2 | 27 comments | | HN request time: 0.202s | source | bottom
Show context
ndsipa_pomu ◴[] No.41912342[source]
I prefer to assign an external name to an internal device and grab a free SSL cert from LetsEncrypt, but using DNS challenge instead as internal IP addresses aren't reachable by their servers.
replies(9): >>41912368 #>>41912827 #>>41913126 #>>41913387 #>>41913720 #>>41913826 #>>41916306 #>>41917079 #>>41917804 #
1. candiddevmike ◴[] No.41913126[source]
Obligatory if DNS validation is good enough, DANE should've been too. Yes, MITM things could potentially ensue on untrusted networks without DNSSEC, but that's perfect being the enemy of good territory IMO.

This would allow folks to have .internal with auto-discovered, decentralized, trusted PKI. It would also enable something like a DNSSEC on/off toggle switch for IoT devices to allow owners to MITM them and provide local functionality for their cloud services.

replies(3): >>41913298 #>>41914996 #>>41916478 #
2. ndsipa_pomu ◴[] No.41913298[source]
I hadn't heard of DANE, so looked it up and found the wikipedia entry: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

According to that, it's not supported by Chrome, nor Firefox.

replies(2): >>41916498 #>>41917893 #
3. 8organicbits ◴[] No.41914996[source]
This would be cool, but I think we're still a far way off from that being an option. DANE requires DNSSEC validation by the recursive resolver and a secure connection from the user's device to that resolver. DoH appears to be the leading approach for securing the connection between the user's device and the resolver, and modern browser support is pretty good, but the defaults in use today are not secure:

> It disables DoH when [...] a network tells Firefox not to use secure DNS. [1]

If we enabled DANE right now, then a malicious network could tell the browser to turn off DoH and to use a malicious DNS resolver. The malicious resolver could set the AD flag, so it would look like DNSSEC had been validated. They'd then be able to intercept traffic for all domains with DANE-validated TLS certificates. In contrast, it's difficult for an attacker to fraudulently obtain a TLS certificate from a public CA.

Even if we limit DANE to .internal domains, imagine connecting to a malicious network and loading webmail.internal. A malicious network would have no problem generating a DANE-validated TLS certificate to impersonate that domain.

[1] https://support.mozilla.org/en-US/kb/dns-over-https#w_defaul...

replies(1): >>41915676 #
4. candiddevmike ◴[] No.41915676[source]
I'll concede that DNSSEC is not in a good spot these days, but I don't know if that's really due to its design or lack of adoption (it's in similar territory as IPv6 TBH). DoH is (IMO) a poor workaround instead of "fixing" DNSSEC, but it's unfortunately the best way to get secure resolution today.

Putting aside the DNSSEC issues, IMO, DNS should be authoritative for everything. It's perfectly decentralized, and by purchasing a domain you prove ownership of it and shouldn't then need to work within more centralized services like Lets Encrypt/ACME to get a certificate (which seems to becoming more and more required for a web presence). A domain name and a routable IP should be all you need to host services/prove to users that domain.com is yours, and it's something I think we've lost sight of.

Yes, DANE can create security issues, your webmail example is a perfectly valid one. In those situations, you either accept the risk or use a different domain. Not allowing the behavior because of footguns never ends well with technology, and if you're smart enough to use .internal you should understand the risks of doing so.

Basically, we should let adults be adults on the internet and stop creating more centralization in the name of security, IMO.

replies(2): >>41916497 #>>41917214 #
5. tptacek ◴[] No.41916478[source]
DANE rollout was attempted. It didn't work reliably (middleboxes freak out about DNSSEC), slowed things down when it did, and didn't accomplish any security goals (even on its own terms) because it can't plausibly be deployed DANE-only on the modern Internet. Even when the DANE working group came up with a no-additional-RTTs model for it (stapling), it fell apart for security reasons (stripping). DANE is a dead letter.

It happens. I liked HPKP, which was also tried, and also failed.

6. tptacek ◴[] No.41916497{3}[source]
It is not in similar territory as IPv6. We live in a mixed IPv4/IPv6 world (with translation). IPv6 usage is steadily and markedly increasing. Without asking to be, I'm IPv6 (on ATT Fiber) right now. DNSSEC usage has actually declined in North America in the preceding 18 months, and its adoption is microscopic to begin with.

IPv6 is going to happen (albeit over a longer time horizon than its advocates hoped). DNSSEC has failed.

replies(1): >>41917884 #
7. tptacek ◴[] No.41916498[source]
It was, once, and then got pulled.
8. 8organicbits ◴[] No.41917214{3}[source]
DANE without DNSSEC isn't a good idea. DoH secures the connection between the user's device and their recursive resolver, but it cannot secure the connection between the recursive resolver and the authoritative name servers. If you're using DANE you need a stronger guarantee that the records are valid.
9. teddyh ◴[] No.41917884{4}[source]
> DNSSEC has failed.

This is the customary comment by me that this is far from the prevailing view. From my viewpoint, DNSSEC is steadily increasing, both in demand and in amount of domains signed.

replies(1): >>41918623 #
10. teddyh ◴[] No.41917893[source]
It’s customarily used for e-mail transport.
replies(1): >>41921257 #
11. tptacek ◴[] No.41918623{5}[source]
Here's .COM and .NET:

https://www.verisign.com/en_US/company-information/verisign-...

Signed domains are increasing where they're done automatically by registrars; where the market has a say, use is declining --- sharply!

replies(1): >>41926486 #
12. tptacek ◴[] No.41921257{3}[source]
No, it isn't; it can't be, because none of the major email domains are DNSSEC-signed to begin with.

Let me know if I've misunderstood your point, and there some other widespread niche usage DANE finds in SMTP.

replies(1): >>41926451 #
13. teddyh ◴[] No.41926451{4}[source]
“Customarily” must not necessarily mean “major email domains”. As I understand it, DANE is commonly used by organizations wanting to secure e-mail between them; DANE enforcement is agreed by both parties, and then used without issue.
replies(1): >>41930841 #
14. teddyh ◴[] No.41926486{6}[source]
As I usually have to point out to you, registrars can’t add DNSSEC to domains. Only DNS server operators can do that. They often have to have the cooperation of the registrar to do it, but not always; sometimes, if the registry supports CDS/CDNSKEY records, the DNS server operator can add DNSSEC all by themselves. And why would DNS server operators add DNSSEC to their domains, unless the domain owners wanted them to?
replies(1): >>41927638 #
15. tptacek ◴[] No.41927638{7}[source]
I'm really not interested in whatever technicality you're trying to argue here. I'm talking about whatever words you want to use for this phenomenon:

https://www.sidn.nl/en/modern-internet-standards/dnssec

Meanwhile: the graphs I posted in the preceding comment are pretty striking. If you haven't clicked through yet, you should. I've pointed out previous, minor drops in DNSSEC deployment in the US. The current one is not minor.

replies(1): >>41954657 #
16. wolf550e ◴[] No.41930841{5}[source]
Didn't they invent MTA-STS so they could not use DANE? They use MTA-STS.
replies(1): >>41954625 #
17. teddyh ◴[] No.41954625{6}[source]
I know that is what MTA-STS is for, but haven’t heard from people actually using it. I have, however, heard from people using DANE in the way i described.

(For those who don’t know, MTA-STS is basically DANE but for people who hate DNSSEC. And are OK with requiring every mail server to also have a web server running.)

replies(2): >>41956791 #>>42077147 #
18. teddyh ◴[] No.41954657{8}[source]
If you can’t get the technical details right, maybe you should hold your piece; this is a technical discussion. I also think you posted the wrong link.

> The current one is not minor.

Maybe not, but I do not know the cause, and you have not proposed one either. Do you have a theory about what happened in late 2023? We’ll have to see if this trend continues; the graphs you linked do show a slight upward turn right at the end of the graphs.

19. tptacek ◴[] No.41956791{7}[source]
Respectfully, what are you talking about? The four largest email providers in the world all run STS. You can test for yourself: just do `dig +short txt _mta_sts.DOMAIN`. I stopped looking after I saw that even Yahoo Mail does it.
replies(1): >>41961090 #
20. teddyh ◴[] No.41961090{8}[source]
I’m talking about hearing from actual people running their own e-mail infrastructure, or who are at least working closely with some local party to run it for them. What the humongous e-mail providers do is largely irrelevant for the purposes of what people in general should do with their own systems; what large providers do is rarely in the interests of anyone else but themselves.

(Also, your test is wrong. It should be “_mta-sts”, not “_mta_sts”.)

replies(1): >>41963941 #
21. tptacek ◴[] No.41963941{9}[source]
What an odd definition of "using it". It only counts if just a couple random people set it up, but not if hundreds of millions of people rely on it.
replies(1): >>41987695 #
22. teddyh ◴[] No.41987695{10}[source]
You frequently argue that DNSSEC usage only counts when it’s added to domains by the domain owners, not when it is added by DNS server operators (who are frequently also the registrars). Why then should MTA-STS usage count if it’s done by the few huge centralized e-mail providers?

When it’s purposefully set up by actual people, I only hear about DANE. It’s only when talking about huge e-mail providers that I hear about MTA-STS. And, as I said previously, those huge providers probably chose MTA-STS not for any reason which benefits their regular users, but for reasons which benefits only themselves, being a huge operator.

replies(1): >>41991701 #
23. tptacek ◴[] No.41991701{11}[source]
No! These aren't comparable problems. MTA-STS is designed to defeat SSL-stripping. It works whether specific users know about it or not. That is not the case for DNSSEC. This is why MTA-STS is overwhelmingly deployed across email users, and DNSSEC has less than 5% deployment (and falling). Thanks for the opportunity to clarify.

If you're wondering why DNSSEC never took off, these kinds of exchanges are illustrative!

replies(1): >>42004941 #
24. teddyh ◴[] No.42004941{12}[source]
> It works whether specific users know about it or not. That is not the case for DNSSEC.

I am baffled by this claim. DNSSEC works completely transparently to the user.

Also, we were comparing the specifics of MTA-STS to DANE, not to DNSSEC. Both MTA-STS and DANE solves the same problem, i.e. fake X.509 certificates and/or protocol degradation (SSL stripping). DANE has the potential to solve the same problem for every protocol, not just SMTP, while MTA-STS is both specific to e-mail, and stupidly requires an additional web server on every SMTP server.

> and falling

It’s actually rising again, according to your sources.

In recent years, you seem to have dropped all pretense of arguing against the specifics of DNSSEC, which is good, but you have then resorted to argumentum ad populum. However, this is a bad form of argumentation unless you can explain why DNSSEC is not as popular as it could be. For instance, what happened in late 2023 to cause the dip?

replies(1): >>42008100 #
25. tptacek ◴[] No.42008100{13}[source]
The chart is right there upthread for anybody interested to see. No, I haven't dropped any of my arguments against DNSSEC.
replies(1): >>42097392 #
26. teddyh ◴[] No.42077147{7}[source]
(This use of DANE is explicitly described in RFC 7672, section 6.)
27. teddyh ◴[] No.42097392{14}[source]
Yes, anyone can see the trend has now turned upwards again. Including you, if you would look.