[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-saag
Subject:    Re: [saag] Comments on draft-foudil-securitytxt-04
From:       Paul Wouters <pwouters () redhat ! com>
Date:       2019-01-10 14:45:52
Message-ID: e46c38e3-6402-9263-6276-79d2cc754b99 () redhat ! com
[Download RAW message or body]

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

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


[prev in list] [next in list] [prev in thread] [next in thread]