Re: [saag] Comments on draft-foudil-securitytxt-04

[Paul Wouters <[e-mail]>]

On 01/07/2019 09:20 AM, Kathleen Moriarty wrote:

> FIRST lists lack of contact information as one of the top 3 challenges of incident responders still.  This and other methods of making contact information accessible could be quite helpful in reducing the number of compromised systems overall.

I do see value in a domain-wide standardized location for this information, whether it is example.com/.well-known/security.txt or security.example.com or a TXT
record in _security.example.com.

That still runs the risk of getting compromised, but that risk is far lowed than a security contact per resource in the organization, and even something the
organization can monitor for.

This of course immediately runs into the problem "what is a separate administrative domain" (aka the public suffix problem)

I think random web servers each with a security.txt will result in mostly bad, outdated or malicious information. People lose track of their VMs, their metal
servers, or even racks of servers. They won't be able to maintain a list of servers or images with updated security information.

And this of course immediately runs into the problem what is a separate administrative domain (aka the public suffix problem)

And I don't agree with you on the "something is better than nothing" argument. We already have the SOA record and the whois output and the HTTP contact email,
so why would adding another one work better than the ones we already tried before?

Put something machine readable in RDAP. It's designed for that. It already properly delegates domains across administrative boundaries. Add a trivial command
line tool to query the security information for a domain (that automatically handles cutting prefixes until it gets the right zone cut, so you can just feed it
the hostname or IP address you want to report on)

Paul