Verifying policy authenticty

[jskiba99]

I’m wondering about how to verify the authenticity of a policy and what it applies to. Would it be safe to say that the policy only applies to the domain in which it’s hosted? In that case would you need a file for each domain? Can policies in child domains reference and delegate its policy to a parent? Can a parent override a child? I assume a parent itself would not be authoritative for it’s children. For targets that are not in contiguous domain namespace or not web related, how to verify the policy does apply to those targets.

This kind of feels like cookies to me. For the robots.txt we would know the policy applies to the target we’re contacting, the same for SSL certs. Could maybe this be implemented along or in addition to a dns TXT record with a similar goal?

As an example if I had a policy on my site at Attacker.com and said Foo.com mobile app for android is in scope, but Foo.com did not have that in scope, who would be authoritative and why? I’m thinking mostly in the context of using the file for automation purposes.

Just spit balling here.

[EdOverflow]

Hi @jskiba99,

This is a valid concern and thank you for raising this issue. Currently my thought is to work together with different companies in the industry to make this work. Essentially we could solve many problems (#14) with an external service/index that monitors security.txt files. Several companies have volunteered to be in charge of this and I hope that we can open source a tool that monitors security.txt files at some point to allow others to follow suit.

I would love to hear your thoughts on this and do you have any other suggestions/possible solutions?

[nightwatchcyber]

Would allowing a PGP or S/MIME signature for the security.txt file help here? Combined with some sort of DNS-based (like DANE) or web based PKI, it may be possible to verify the signature then.

[nightwatchcyber]

We also should clarify what the thread model is and what can happen if the file is compromised or forged. I assume if that happens, the attacker can now start collecting security reports about a domain and can hone their attacks further.

Good example of this modeling discussion can be found in the ACME protocol that is used by LetsEncrypt:
https://tools.ietf.org/html/draft-ietf-acme-acme-07#section-10

It also seems from ACME that HTTP challenges are good enough of a proof to issue SSL certificates. If the level of threat is the same as here, then maybe authentication may not be as important.

One more idea to throw out - we can also require or recommend that "security.txt" files be always loaded over a valid TLS connection. Not sure if that will actually work in real life.

[rhymeswithmogul]

I like the idea of requiring security.txt be loaded over HTTPS, but a lot of small companies rely on cheap Web hosting that only supports HTTP. To ensure the widest adoption, I think the next draft of the RFC should read "security.txt SHOULD be loaded over HTTPS" rather than "MUST be loaded."

With that in mind, having some kind of second factor to authenticate the security.txt file would be a great enhancement. There could be a line such as PGP-Signature: <url> for detached signatures, or the RFC could be amended to allow for inline signatures, with something along the lines of, To allow security.txt to be cryptographically signed with PGP, user agents MUST ignore any lines not in the 'Thing: Value' format.

[EdOverflow]

This issue has been resolved in 53931bd. The section still needs a lot of work, but the general idea is already there.