Scope field

[nightwatchcyber]

How should the scope be declared to cover a domain and all its subdomains? The latest draft restricts the scope to the publishing domain name or IP address only, but for our university I would like to explicitly declare a domain with its subdomains and IP space (CIDR blocks) to be under one declaration. Publishing a security.txt on each of our resources is not feasible.

Maybe a separate Scope: field?

[joker314]

We must be very careful which domain names are capable of extending their scope to which other domain names. We must avoid this sort of attack:

# on attacker's site
Scope: https://victim.com
Contact: attacker@example.com

which would allow the attacker to harvest vulnerability reports intended for the victim site.

[twaijn]

I think other domains and IP addresses should probably be left out of the Scope field (fetching a security.txt over HTTPS using an IP address URL shouldn't work anyway). It would be sufficient to declare that the security.txt is applicable to subdomains also.

[DevQps]

I would like to bring this issue to the attention again. Since the RFC currently states that a security.txt record only applies to the domain from the URL it was retrieved from (i.e. https://example.com/.well-known/security.txt only applies to example.com but not to subdomain.example.com) this causes major overhead for organizations (in my opinion).

Why this is a problem?

Let's say we have an organization with a domain containing X sub-domains that all point to different systems with a different IP address. Since the current RFC states that security.txt file only applies to the exact domain being queried, this means that for each of these sub-domains to be covered by a security.txt record, each of those X systems behind these sub-domains would need to set up a webserver to either serve the security.txt itself or to do any redirection.

There are many systems within organizations that do not always run a webserver, so the extra overhead on setting up these webservers solely to serve a security.txt is quite a lot. These systems also have to be maintained, and the security.txt records would have to be updated as well, which creates an extra burden on the organization and might increase the attack surface of an organization as well. Depending on how large the number X is (amount of sub-domains and systems) this can become quite hard to manage.

Proposed Solution 1: Change the RFC and make security.txt cover sub-domains.

The most simple solution would be to change the RFC to specify that a security.txt record applies to it's sub-domains as well, unless the sub-domain specifies a security.txt record on it's own (this would then override the security.txt record of the parent).

Advantage:

• The advantage of this is that existing security.txt records would not have to be changed. I personally think that many organizations are already using security.txt this way (and only specify it on the second-level domain).

Downside:

• Organizations that do not want to receive reports for sub-domains (i.e. cloud providers, etc), would potentially receive reports of vulnerabilities in systems pointed to by sub-domains.

Proposed Solution 2: Extend the RFC and add a "scope" field.

Another solution would be to extend the RFC with a "scope" field which specifies if sub-domains are covered as well.
You could choose to allow the security.txt author to include sub-domains by listing them.

Security.txt file from: https://example.com/.well-known/security.txt

...
scope: x.example.com, y.example.com, z.example.com
...

Advantage:

• It gives an organization the flexibility to include certain sub-domains in the scope of the presented policy.

Downside:

• It leaks the sub-domains of an organization. Especially organizations with many sub-domains might not want this.

Proposed Solution 3: Extend the RFC and add a "cover-subdomains" field.

Another option would be to add a cover-subdomains: true option (or something similar).

Security.txt file from: https://example.com/.well-known/security.txt

...
cover-subdomains: true
...

Advantage:

• The advantage of this is that sub-domains will not be leaked to a potential attacker doing reconnaissance but at the cost of lost flexibility.

Downside:

• No flexibility in which sub-domains are covered (either all or none).

I am looking forward to feedback, and whether or not other people recognize this as a problem!

[nightwatchcyber]

The most appropriate option for extending the original RFC is via a new field. Changing the RFC itself will take too long, so options 2 or 3 would be the best fit

[DigitalTrustCenter]

Thank you DevQps for pointing this out and bring it to attention again, since we also think this should be improved in the RFC.

Proposed solution 1 would be the easiest and most preferable in our opinion, however we are not fully aware of what kind of change process and time this would take to get it changed in the RFC. If solution 1 cannot be implemented solution 3 would be the next best of your proposed solutions. But you could also think of a solution 4 and 5 which is a combination of the solutions that you did suggest.

Solution 4:

Combine solution 1 and 2. Solution 1 to cover all subdomains by default under security.txt of the first level domain name. The scope field is added as optional, and allows you to to specify the scope if you want so.

Solution 5:

Combine solution 2 and 3. In that case you could make the field "cover-subdomains" required and the "scope" key field optional.

I can imagine that some organizations with specific use cases do want to make a distinction, in that case they are free to use the optional field.

Which ever solution you take, the RFC should also specify the prioritization in which security.txt has the most authority above other. For example test.example.com has a own security.txt and example.com has a security.txt. I would say that for test.example.com, the priority security.txt is the one on test.example.com. If security.txt is missing from test.example.com, the one on example.com should be used for test.example.com. The priority of the security.txt is the one on the most specific domain name (the one including the subdomain(s)) to the least specific domain name.

[DevQps]

@DigitalTrustCenter @nightwatchcyber Are you both interested in holding a meeting about this to try to work toward an extension for this?

[DigitalTrustCenter]

good idea! let's wait for the response of nightwatchcyber.

[nightwatchcyber]

Feel free to put together a proposal, however, the security concerns regarding a domain impacting its subdomains are not trivial and this is the reason why we dropped this functionality from the RFC

[underdarknl]

In my opinion there is added complexity when dealing with subdomains that are delegated to a different zone by for example a CNAME record.
Asking the top level domain owner to potentially declare rules for all their subdomains (using the cover subdomains or scope fields) will give them the possibility to include systems not in their control (either because the record was changed, or the ownership of the referenced IP or zone was not changed).
Furthermore, giving a declaration on my domain while including all subdomains, and then setting one of my subdomains to include for example google.com or their ip addresses should not take precedence over their security.txt file. But, since theirs is not being hosted on the hostname I gave that IP, nor can it be securely accessed from the direct ip address bound webserver. it's not possible to know which security.txt takes precedence.

Ideally, I think, a security.txt url would be bound to the domain by dns, either as a txt record for a given domain or subdomain, or by rdns or whois/rdap for a given ip-address or range.

N.B. it is possible to obtainan ssl cert for ip-addresses. but its very uncommon.