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

[Paul Wouters <[e-mail]>]

On 01/08/2019 08:06 PM, Randy Bush wrote:
>> If http://example.com is compromised, and you grab
>> http://example.com/security.txt,
> 
> don't do that
> 
> and, in anything but trivial environments, it is foo.example.com that
> is compromised and the security.txt is on example.com

First, in _most_ domains, APEX and www. are all there is, and usually the same server. So you have no choice but to grab it from the compromised host. Are you
saying this method should not be used at all for the majority of websites because of this limitation? So what if www.nohats.ca is bad and you want to find my
security.txt? Turns out www.nohats.ca is the same as nohats.ca. You cannot just curl for the security.txt because you might get redirected to the bad server.
And what do you if those are the same? Should the draft talk about this?

Also, to me it had not been clear that the intend was to only put it on the main domain and not on each server within the domain. I thought the problem being
addressed was that there is ams.nl.service.example.com and that a contact from whois/rdap for the whole example.com would not lead to the right contact, and so
instead the server itself would publish a security.txt. But it seems now that people would need to crawl for zonecuts because it is planned to only appear at
the apex or "subdomains" as I read it now:

   The file is named "security.txt", and this file SHOULD be placed
   under the /.well-known/ path ("/.well-known/security.txt") [RFC5785]
   of a domain name or IP address for web properties.

[Note I had not realised the subtlety of "of a domain name". I think the draft should make it very clear how to handle reporting hosts within a domain using the
 top level domain. If the idea is that for www.example.com you go to a example.com/.well-known/security.txt it should be made more clear. And then talk about
the problem of the apex and www. being the same host]


   Some examples appear below:

   # The following only applies to example.com.
   https://example.com/.well-known/security.txt

   # This only applies to subdomain.example.com.
   https://subdomain.example.com/.well-known/security.txt

   # This security.txt file applies to IPv4 address of 192.0.2.0.
   http://192.0.2.0/.well-known/security.txt

[note: this ending in .0 is very confusing. Is it mean to cover the whole /24 ?]

   # This security.txt file applies to IPv6 address of 2001:db8:8:4::2.
   http://[2001:db8:8:4::2]/.well-known/security.txt

   # This security.txt file applies to the /example/folder1 directory.
   /example/folder1/security.txt


Here, the "subdomain.example.com" hides the problem of not knowing administrative cuts. Is toronto.bank.site a domain or subdomain? What about
paul.lawyers.website? what about example.gc.ca ? or example.gc.com ?



So where do you now find a security.txt for  ams.nl.service.example.com ? It seems the draft now dictates you:

- look for a subdomain zonecut for nl.service.example.com
  - if found, look for /.well-known/security.txt
    - if not found, look for /security.txt
- look for a subdomain zonecut for service.example.com
  - if found, look for /.well-known/security.txt
    - if not found, look for /security.txt
- look for a subdomain zonecut for example.com
  - if found, look for /.well-known/security.txt
    - if not found, look for /security.txt
- look for server named .com
  - if found, look for /.well-known/security.txt
    - if not found, look for /security.txt

And that's before we start talking about how to handle HTTP vs HTTPS resources which could end up on different VHOST configurations.

As for the examples for the IP address, I'm also confused. If 193.110.157.66 needs to be reported on, and I should not go to the compromised
host itself, so not try  http://193.110.157.66/.well-known/security.txt? Do I have to try http://193.110.157.0/.well-known/security.txt or
do I try http://157.110.193.in-addr.arpa/.well-known/security.txt ? Also if the /24 is malicious and I want to go "one level up" that's also
a really hard problem, because now you need to do DNS queries to see if this is a /24 from a /16 or straight from the RIR.

The document should really elaborate on these scenarios. The examples only illustrate more problems, and more possible unclear locations of where
to find these. I doubt any of these will ever see a real use because of the problems I cited above.

Paul