search

disclose / dnssecuritytxt

A standard allowing organizations to nominate security contact points and policies via DNS TXT records.
https://dnssecuritytxt.org
MIT License
30 stars 7 forks source link

DNSSEC not mentioned #6

Closed m-ueberall closed 3 years ago

m-ueberall commented 3 years ago

http://dnssecuritytxt.org/#frequently-asked-questions mentions

[…] Since DNS is typically more permanent than individual web hosts and the text files they hold, a DNS Security TXT record is more authoritative.

However, it does not refer to DNSSEC anywhere to substantiate this claim.

yosignals commented 3 years ago

Hey @m-ueberall thanks for reaching out, what do you want to happen with your issue here?

Am I misunderstanding, you think that dnssecuritytxt is associated with DNSSEC ? what DNS Security TXT is, is a Text Record for security information hosted in your DNS records - these records can be hosted with any configuration DNSSec or otherwise, there is no impact.

m-ueberall commented 3 years ago

While dnssecuritytxt is clearly not associated with DNSSEC, I'm questioning the "more authoritative" wording/claim in the FAQ.

As mentioned in issue #7, there's an earlier Internet draft ("A File Format to Aid in Security Vulnerability Disclosure"); why should one way to specify information be more authoritative/permanent than another if we're talking about a certain location? Sites that support .../.well-known/security.txt will usually ensure that it (here: a certain directory/file) cannot be overridden/overwritten locally or made unavailable by mistake--by means of internal monitoring.

However, to protect against ill intentions (likely by a third party) like DNS cache poisoning/spoofing, DNSSEC can be utilized. By relying on a file served by a web browser, clients may or may not be able to detect changes regarding the TLS certificate, but it's more difficult to verify whether this could be intentional. Again, a DNS CAA record could be checked but all in all, one could argue that there's not necessarily a comparable root of trust in place in this scenario w/o (also) relying on DNS entries. Therefore, the dnssecuritytxt approach could be characterized as "more unified" (by not relying on other roots of trust), but by default, no cryptographic signatures/means of validation are in place to verify whether the original owner provided the information in retrieved DNS records.

Hence, without any explanation, the "more authoritative" in the FAQ simply cannot be justified.

yosignals commented 3 years ago

Hey @m-ueberall thanks for your time, we've kinda discussed this and thought about this, I think in the shortest possible terms we can frame it like this:

So - factually, you need a web server (or a public folder) to host the security.txt (and internal monitoring ?) and secondarily, DNSSEC is an architectural feature that while an excellent defence against the attacks you have mentioned has nothing to do with the principle.

With regards to DNSSEC that is a configuration that isn't something we can enforce, I fully agree with you DNSSec is a force for good and its adoption is growing (again) but this isn't the place to tell people that it's mandatory because whether I like it or not there may be conditions to why orgs haven't implemented it yet or at all

If a security.txt resides on a domain (with a webserver or public folder to host, that has DNS security flaws, then everything underneath it pays the price (because it's more authoritative)

I'm not sure the value of changing the language based on an external Schrodinger of having or not having DNSSEC - I'm fine with calling it more authoritative because it is, and I think you know that based on how you write and your knowledge

yosignals commented 3 years ago

OK, Closing this, but in short, we perceive it as more authoritative because it's at the root of an organisations domain, parental to any sub-projects (such as subdomains ) and with less dependency if we consider an organisation online they will have a domain and under that domain, they will have services, subdomain and subdomain services, this in our view is the most parental position to provide security contact information and for that, dealing with the root of the domain qualifies as dealing with the most authority with regards to security contact on the domain - it makes more sense to use the security contact information on acme.com DNS TXT records than a webserver or public exposed folder on acme.com/.well-known/security.txt or than serviceoffering.acme.com or serviceoffering.acme.com/.well-known/security.txt - it's been good to think about, and thank you for joining in @m-ueberall