Figure out how to use DNS to secure the security.txt signature

[nightwatchcyber]

From an email to the IETF SAAG list:

The proposed "security.txt" file has a matching optional "security.txt.sig" file. One of the common issues we have received as a feedback from potential users is a need to safeguard against the possibility of an attacker compromising the webspace of a given domain, and putting their own "security.txt" and "security.txt.sig" files there. This will result in an attacker now receiving reports about potential security issues in the compromised target.

One of the proposed ways to try to fix this issue is to use DNS as follows:

• to store the digital certificate that was used to generate the signature file
• OR to store the signature itself in DNS
• OR to store the entire "security.txt" file in a DNS record instead of being accessible via the web

The logic behind this proposed solution is that web space tends to get compromised more often and easier than DNS for any given domain.

What I am wondering if there are any currently best accepted practices to accomplish these goals in DNS with minimum disruption to the Internet architecture as whole. Possibilities I was thinking of is using DANE and OPENPGPKEY records; CERT records, or perhaps even TXT records like DKIM and SPF.

Any recommendations, suggestions or comments are welcome.

(related to #28 and #35)

[nightwatchcyber]

Another proposal I just posted here:

I specifically want to ask about the idea that Randy Bush mentioned -
generating a hash of the security.txt file, and placing it in DNS as a
simpler way to verifying the integrity of the file. This would also
avoid a separate signature file, and mucking around with certs.

As mentioned earlier by Stephane Bortzmeyer, the goal would be
something lightweight. Another design goal would be to "good enough"
security, as opposed to perfect security. As Stephane as noted in
another message:
https://www.ietf.org/mail-archive/web/saag/current/msg08126.html

I suggest we do not try to find out whether DNS is secure than the Web
or the opposite. Instead, we could rely on the fact that it is at
least harder to compromise both DNS and the Web than the DNS alone or
the Web alone. So, putting info in the Web and a way to check it
elsewhere (in the DNS) seems reasonable. We don't want a
military-grade solution, just something that it is not obvious for an
attacker to compromise.

The proposal would be as following:

• After someone creates the security.txt file, they would calculate an
  SHA-256 hash, and then place it in DNS of the same domain or subdomain
  as the one serving the "security.txt" file
• The hash would specifically be placed under
  "hash._securitytxt.example.com", as per RFC 2782, in a TXT record
• The format of the hash would be the hex representation of SHA-256 -
  something like:
  e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
• Possible extensibility may be accomplished by using a format like:
  sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

I am aware of both RFC 6920 and 8315 but I think their encoding of the
hash may make this too heavy to pull off for most admins. What I was
thinking of is more like the following draft which never ended up
being approved:
https://tools.ietf.org/html/draft-thiemann-hash-urn-01

The level of effort involved here would be pretty much the same as
putting in SPF records, and way less complex that DKIM which involves
keys.

[jeroenh]

It would be good to consider the practical implications of the proposal here. In many organisations there are separate teams that run DNS, Web and Security. Publishing a security.txt would involve all three. Ideally, after that, you ideally have minimal interaction between those team to enable updates.

If you go the route of publishing a hash of the signature file, you need the Web and DNS publication to be completely in sync. Which in itself is already hard, since Web and DNS have different caching models. So both from a technical as well as operational perspective there is a high chance of asynchrony.

If you publish a public key in DNS that is related to the signature that is published through the website, you have some safeguards against tampering. It's not as big a guarantee as the signature itself, but at least it's some assurance. The big advantage of that approach is that you don't need changes in DNS to update the security.txt file, so less chance of the two not being in sync.

For both options I'd recommend having DNSSEC, otherwise the value of having those records in DNS is next to nothing. DNSSEC would also handily solve problems of key rotation that is involved in the signature, since you can use the existing trust of DNSSEC to handle that.

[nightwatchcyber]

Deferring to future work, same as # 35 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.

[nightwatchcyber]

Will add a DNS example to the Signature field since it is a URI

[nightwatchcyber]

Will add a DNS example to the Signature field since it is a URI

Signature directive was removed in -05, deferred to future

[nightwatchcyber]

Related to #35

[wiktor-k]

Another variant would be to put the fingerprint of the key that would be used to cleartext sign the security.txt file (either on domain apex or special subdomain, like in _dmarc).

Random example that I just thought of:

example.com. IN TXT "security=openpgp4fpr:653909a2f0e37c106f5faf546c8857e0d8e8f074"

This way one would have to do a little bit of work initially to involve DNS teams to put the record there but all updates to security.txt - as long as they would be signed with the same key - would still be easily possible thus solving @jeroenh problem.