Allow to store "security.txt" contents in DNS TXT RR about security-txt HOT 20 CLOSED

A single DNS response (UDP) is limited to 500 bytes before fragmentation. A single security.txt might fit in a DNS TXT field, but even a moderately large file would be too large.

There's also the entire issue of DNS hijacking. If the problem is in DNS, then how do you access DNS to identify the security contact point?

I think it's best to keep the actual contents of security.txt out of DNS. But DNS would be an option for storing a checksum so users can be certain that the web server's security.txt is valid.

from security-txt.

@hackerfactor: Regarding DNS hijacking, DNSSEC allows to at least partially mitigate attacks (there are other countermeasures, see [1] for a short overview). In such a hijacking scenario however, how can you be sure that the web server you contact in order to obtain a text file is the correct one in the first place (unless, of course, the site uses OV/EV TLS certificates and/or potentially (also) HPKP)?
Fragmentation should not be considered a problem nowadays (see the SMIMEA[2], OPENPGPKEY[3] drafts which already suggest to store more than 500 bytes)–if your local name servers have a problem with that, it should be possible to query the site's own name servers.
Using DNSSEC signatures also means that you already have a checksum for all entries in question, no need to add another signature.
Lastly, storing the security.txt related information in (one or more!) DNS resource records and marking it as authoritative for the domain in question (NB this is not yet addressed by the current draft) might be a much more feasible option for companies/institutions that have a lot of different, publicly accessible servers which are administrated by different teams (think risk of inconsistencies etc.)

[1] The Risks of DNS Hijacking Are Serious and You Should Take Countermeasures, https://thenewstack.io/risks-dns-hijacking-serious-take-countermeasures/
[2] Using Secure DNS to Associate Certificates with Domain Names for S/MIME, https://tools.ietf.org/html/rfc8162
[3] DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP, https://tools.ietf.org/html/rfc7929

from security-txt.

👍 for storing a hash in DNS, 👎 for storing contents in DNS for the reason @hackerfactor pointed out.

(A related discussion about this is going on over in issue #19.)

from security-txt.

It is also possible to define a new DNS record type, like the one just created for CAA:
https://tools.ietf.org/html/rfc6844

from security-txt.

@nightwatchcyber I've been playing with an implementation that is structured like SPF (RFC4408) records. Certainly interested in figuring out what the requirements are for something like this and what the implementation would look like.

from security-txt.

@austinheap - biggest problem with using DNS is size limits, I looked at a bunch of recent RFCs that use DNS TXT records, and most of them mention the size issue and recommend 200 bytes as a good limit. When SPF and SenderID were originally proposed, there were significant discussions around that as well.

I also want to point out a use case of where DNS is important vs. a web-based file: where a domain has not web space. Some domain names that are used for non-web traffic like email, SIP, etc. will not necessary have a website and that is where DNS or email would become an important contact point.

from security-txt.

@nightwatchcyber I'm certainly not suggesting the contents of the security.txt file be placed in DNS and agree the size limit makes that approach a non-starter.

Re: the different use-cases for non-HTTP(S) properties, I agree that needs more investigation. There's a good conversation going on related to this over in issue #30.

from security-txt.

+1 for a DNS option. Every so often, I do run across the occasional company that has email service for their domain, but no Web site. For example, if there were a security flaw on contoso.com's SMTP server, but they didn't have a Web server to host a security.txt file, we're back to square one.

Were a "SECURITYTXT" resource record type to be formalized, I second @nightwatchcyber -- the CAA format would fit this nicely.

from security-txt.

• I am not in favor of a hash value, as the risk of misalignment with the original security.txt is too big.
• I am also not in favor of defining a dedicated resource record type such as SECURITYTXT. The TXT RRtype works well. The 512 byte limit is not an issue on modern name servers nowadays (due to EDNS).
• DNSSEC, should be a MUST.

A working example is in my own zone file:

_security.forfun.net.	7199	IN	TXT	"Contact: [email protected]"
_security.forfun.net.	7199	IN	TXT	"Acknowledgements: https://www.forfun.net/humans.txt"
_security.forfun.net.	7199	IN	TXT	"Encryption: https://www.forfun.net/E96FE9DC_pubkey.asc"
_security.forfun.net.	7199	IN	TXT	"Disclosure: Partial"

from security-txt.

The limits for DNS size mentioned here (500 and even 200 bytes) are ridiculously low, much lower than what we use today for the DNS. The priming response from the root (without DNSSEC) is 811 bytes. The DNSSEC keys for .com are 743 bytes with their signatures.

from security-txt.

@nightwatchcyber Before deciding to request a new DNS RR type, be sure to read RFC 6686 (why SPF dropped the SPF RR type). Basically, there is a big deployment problem, from broken middleboxes dropping DNS requests with QTYPE they don't understand, to Web forms to edit DNS zones as proposed by most DNS hosters.

from security-txt.

@bortzmeyer - is there a practical size limit in DNS right now?

from security-txt.

@nightwatchcyber The theoretical limit is 65536 bytes but it is unrealistic in practice. There are two practical limits, 4096 bytes is the maximum EDNS size for most servers, but 1460 is a more realistic one, avoiding IP fragmentation.

from security-txt.

It seems like anything that would encourage substantially larger DNS records is, in itself, a security risk, considering how DNS reflection & amplification attacks work.

from security-txt.

@davidmays I hope that, in 2018, everyone deployed RRL and DNS-over-TCP...

from security-txt.

Sadly, I suspect it will not be the case, and that many misconfigured systems will still provide avenues for such attacks. :( But I am a cynic when it comes to these things.

from security-txt.

Whether we created our own DNS resource record type or settled for a well-known TXT record, there are other DNS records that could be far larger. Resource records like CERT, IPSECKEY, OPENPGPKEY, and TLSA (with a full certificate) may hold several kilobytes of data, far more than any compliant security.txt file ever would.

I do hope that all the major DNS server operators have implemented DNS-over-TCP or some sort of rate limiting by now, but I feel that's out of the scope of this project. All we can do is urge any company running a vulnerable DNS server to quickly create a security.txt file.

from security-txt.

DNS data can handle a lot more then the amount of data needed here. And amplification protection can be done simply by using TCP or insisting on DNS-COOKIES for these answers. This is a generic DNS problem is solved by DNS people and there is no need for additional requirements here.

What does concern me here is the added level of indirection. mdavid's example records above show the DNS pointing to a openpgpkey ID by filename, to some webserver, which adds a new weak link if that domains DNS (not necc the same as the webserver/domain in question) or that webserver is compromised. The fingerprint of the openpgpkey should be within the DNS record data, so it is protected by DNSSEC.

But I still think using RDAP (the WHOIS replacement) is a much better place for this kind of data.

from security-txt.

We will defer this and #91 to the future since it would be out of scope for this draft specifically. May want to consider making a new draft in the future just for DNS.

from security-txt.

Related to #91

from security-txt.