disclose/dnssecuritytxt

A standard allowing organizations to nominate security contact points and policies via DNS TXT records.

dnssecuritytxt

A standard allowing organizations to nominate security contact points and policies via DNS TXT records.

This proposal was first made public on March 25, 2021 and is is currently a draft. We welcome comments and feedback! To make suggestions please submit a PR via Github or submit a ticket. Thanks for your interest!

Find us on Twitter: https://twitter.com/dnssecuritytxt.

Created with <3 by John Carroll and Casey Ellis for The disclose.io Project.

dnssecuritytxt's Issues

Suggestion: do not use the apex approach for deployment

See 'txt cnn.com'

The apex is already polluted enough as it is. I suggest to only use use the underscored node name '_security'.
(normative reference could be: RFC8552)

Expires and/or Verified Field

Much like the HTTP Security.txt, I think that DNS Security TXT records should implement a date field for either expiration or last verified.

The purpose of this field is to ensure the validity of the document with respect to elapsed time. There are pros and cons to either one of them, as well as pros and cons to adding both. In this essay I will...

Field Format

For both proposed fields that are discussed within this issue, the following format is proposed:

f=YYYYMMDD

The field identifier has been shortened to the first letter of the field in optimize for minimal impact to the length of the record. This could be considered optional, with the full field name also being considered valid.

The value of these proposed fields follows the ordering of ISO 8601 dates, however the field separators (-) have been removed in order to optimize for the character length restrictions inherent to TXT records. Time has been omitted from the field due to the unlikely relevance of it to a particular researcher, as well as to further optimize for the aforementioned character length restrictions.

Field Separator

Due to this additional metadata being added to existing records, a field separator must be introduced. I believe that two separators should be considered for inclusion: ; and . Existing TXT record formats, such as SPF, make use of a space to serve as a separator, while other records, such as DKIM, may use ; as a separator. I do not believe we need to support both, but we should support at least one.

Example Record

A new record using one of these fields might look like this:

e=20210901; [email protected]

Expires

Syntax: e=YYYYMMDD

By allowing domain administrators to set an e= field on their relevant security TXT records, it gives them a way to indicate to researchers that the data should be considered valid until a particular date, after which it should be considered out of date.

Pros of Expires

• It sets a clock by which it is the domain administrator's job, or the security team's job, to update the record.
• Because it is a future date, it can be easy to write automation around in order to be reminded when it's about to expire so you can update it
• Aligns with the security.txt required field "Expires"

Cons of Expires

• Security teams get busy, domain admins forget, and the language of the standard, as well as the very nature of the term "expires", suggests that the data included in the record is no longer valid, even if it is. As a researcher, if I find an expired policy or expired contact information, do I just yolo my research in that general direction? Otherwise, what do I do with this expired data?
• Recommendation in the security.txt field is to use less than 1 year to avoid staleness, and we'd probably want to align with security.txt wherever possible. The failure modes have effectively become "This data is expired" or "this data has an expiration so far in the future that it's probably never been updated." Either of these failure modes may encourage a domain administrator to automate the updating of the field, which then ceases to ensure any validity about the contents therein.
• Because it is always a future date, performing research on security TXT records themselves can be more complicated, since that research would have to regularly query the record, identify the change to e=, and then document it as such. It would not give reliable insight into how regularly the information is actually being updated other than in increments of how quickly we can scan for it.

Verified

Syntax: v=YYYYMMDD

By allowing domain administrators to set a v= field on their relevant security TXT records, it provides a way to indicate to researchers that the data is accurate as of a particular date.

Pros of Verified

• Any changes to the record(s) basically have to be conducted in such a way that it's easy to also modify the verified field
• Provides a marker by which to indicate to researchers that the data is no more than X days old
• By using verified instead of modified, it allows us to increment the date without necessarily indicating that the policy or contact has changed.
• It avoids language that suggests that the data herein is somehow invalid and instead just promises that it was valid as of a specific time.
• It is an incrementing field, making it easy to store information about changes to it in a time series, enabling broader internet-wide research about how regularly security teams are validating their security contact / policies information.

Cons of Verified

• This is a deviation from the security.txt field (although I would like to pitch an Optional verified field to security.txt via whatever means necessary to do so)
• Because it's a present date, it is easy to set it up and then forget to ever update it, resulting in stale records. There is no upper bound on the validity of the record.
• This is also prone to automation which then ceases to ensure any validity about the contents therein

Expires AND Verified

Syntax: v=YYYYMMDD e=YYYYMMDD

This approach considers the addition of both aforementioned fields.

Pros of Implementing Both

• Implementing both would neatly give an upper and lower bound for the validity of any contact or policy information
• Not updating within the expiration window still results in useful validity information to the researcher, who gets information from the v= field about when it was last valid.

Cons of Implementing Both

• TXT records are only 255 characters long, meaning addition of two new fields for a record could be challenging for particularly long contact or policy URLs or for future uses of the record
• More work on behalf of admins to update both fields, which could result in automation, which as previously identified, is not good for ensuring the validity of the information.

Conclusion

Regardless of the specific implementation chosen, the value gained from the inclusion of time-based validity for these records should be considered.

RFC9116

The website says: "Just as security.txt can be deployed into either the root or the .well-known directory of a webserver,...", but with RFC9116 this is no longer true. RFC9116 says: "For web-based services, organizations MUST place the "security.txt" file under the "/.well-known/" path"

UPDATE: In "3 Location of the security.txt File" it says different, so I was wrong. Please close ticket.

Put record somewhere other than apex

Zone apexes are getting really crowded with stuff, and using multiple TXT records to jam information in there seems to be not a scaleable way to approach the issue. Perhaps choose some other method like _security.example.com TXT "text here" - overloading the apex is dangerous and will lead to very complex and fragile sets of data in second-layer parsing trees. Other than that, this seems like a reasonable thing though I suspect that only the clueful and less-broken people will end up using it which is not the audience that probably needs to be implementing it.

Suggestion: Allow for linking to `security.txt` (or other external resources) specifying a checksum

For sites which already maintain a security.txt file (see A File Format to Aid in Security Vulnerability Disclosure) which also allows specifying preferred languages and encryption keys, it might not make sense to maintain DNS TXT records unless they simply link to https://example.org/.well-known/security.txt.

As pointed out, the obvious challenge [on the other hand] is that it inserts the owner of the web host between the user and the contact channel and policy details. This is true for all external references by means of a URL, of course.

DNS entries can be secured with cryptographic signatures (see DNS Security Introduction and Requirements), but a simple URL specified above—regardless of what it refers to—only specifies the location, but does not provide a means to validate the contents without the aid of additional roots of trust. While the latter should be used if available, an additional checksum provided as part of the DNS entries could at least be used as "last resort" (or rather, to utilize DNSSEC to its full extent w.r.t. this use case).

DNSSEC not mentioned

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.

security_enc conversation

While an email and or a URL is the absolute minimum it may also be prudent to allow for encryption method for communications maybe gpg and keybase

For me I'm on the fence, such as following the K.I.S.S (Keep It Stupid Simple) principle, arguably the email and or URL is enough to signpost (job done ?) the next

declaire the encryption presence with security_enc followed by a schema identifier and the key/id

Some examples( We spitballing):
GPG Short Key ID
security_enc= GPGSK:AAAAAAAA

GPG Long Key Example
security_enc= GPGLK:AAAAAAAAAAAAAAAA

GPG Fingerprint
security_enc= GPGF:AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

Keybase Fingerprint
security_enc= KBF:AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

My thoughts are, having it as a supported parameter is a secondary question to the main question:

Where can I have a security conversation ? - do we want to introduce another question that is how can I speak to security, or should that be left as part of step two in a conversation ?

Open for thoughts

Is this effort still alive?

Is this effort still alive?

Since there has not been any contributions for quite a while (for as far as I can see). I was wondering if this effort was still alive.
Security.txt because an official RFC some time ago (https://www.rfc-editor.org/rfc/rfc9116) but it requires the use of a webserver which can be perceived as overhead in some cases.

It would be great if we could push this effort forward to an official RFC which complements security.txt in the world of vulnerability notification. I would be willing to help write the RFC, but I would first like to sync with you guys about the work you have already done in this area.