Subject: [saag] DNS hash proposal for security.txt

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 Feb 2018 21:33:19 -0500

Hi,

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.

Thank you

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 15 Feb 2018 22:00:46 -0500

> On Feb 15, 2018, at 9:33 PM, Yakov Shafranovich <[email-masked]> wrote:
> 

If DNS is simple and secure enough to publish the hash, why not dispense
with the hash, and just publish the data in the DNS?  The SOA record already
has an "mrname" field.  It is not always populated with a working contact,
but it should be.  We should keep in mind that neither will every site publish
security.txt.

For every server with a DNS name, one can find the zone's SOA record via:

	dig -t SOA some.server.example.

this yields the SOA record in the answer section if "some.server.example"
is at a zone cut, or in the authority section if not.

If for some reason the zone contact will not do, and a new "more specific"
record is needed, why not just publish the email addresses there?  What's
the purpose of the extra indirection with hashes of "security.txt"?

Coordinating the hash updates with updates on the server will not be fun.
I predict >50% of any published hashes would be wrong within a year of
initial publication.  There'd be no "pressure" to keep them up to date,
until it is too late in a crisis.

So, NO, the hashes in DNS approach is not viable for this.  Put the data
in one place or don't bother at all.

-- 
	Viktor.

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Feb 2018 20:31:39 -0800

> generating a hash of the security.txt file

i did a sha256 of the signed version, security.txt.sig

> 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.

that's not unreasonable

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Feb 2018 20:32:33 -0800

> with the hash, and just publish the data in the DNS?

i like that the attacker would need to corrupt two data sources

randy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 16 Feb 2018 15:40:22 +1100

> i like that the attacker would need to corrupt two data sources

It's still really only one here.  If the attacker can write to DNS,
then they can write A/AAAA records and TXT at _acme.<domain>.  I guess
that involves an active, ongoing attack, so it's still better than a
single compromise.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 Feb 2018 01:47:56 -0500

> On Feb 15, 2018, at 11:32 PM, Randy Bush <[email-masked]> wrote:
> 

May sound good in theory, but a complete non-starter in practice.  Too
much complexity for too little gain.  Setting the bar too high is
counter-productive.  Let's not keep making the same sort of mistakes
that required rfc7435 to dispel.

-- 
	Viktor.