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

From: Paul Wouters <[email-masked]>
Date: Sat, 5 Jan 2019 14:21:34 -0500

On 12/31/2018 03:05 PM, Salz, Rich wrote:
> I think it is silly to have an automated security.txt that doesn't have TLS.

Whether it uses TLS or not is completely irrelevant. The security contact is supposed to be easy to find public information. What attack is forcing the use of
TLS supposed to prevent? The server is already compromised (hence the need for the info) so it is easier to modify the source, then modify it in transit.

On a compromised server, you cannot trust the information regardless of PGP, TLS or anything else. I think it is irresponsible to use a security contact
provided by a compromised device to report on the compromise and it is irresponsible for the IETF to standardize such a flawed approach that decreases security.
If it was harmless, I wouldn't care, but it actually is problematic. Anyone who thinks this is a bad idea, _still_ has to provide a security.txt if it becomes
a standard, and somehow has to keep monitoring the content/status of those files for each webserver they run to prevent disclosures from reaching the hackers.
Hackers who might realise that they are caught and rm -rf the server in an attempt to hide their tracks.

Additionally, it will have all of the same issue of whois contact information:
- outdated, unmaintained
- spammed to hell
- encrypted emails can no longer be read due to person no longer works there, passphrase or private key lost

Put this information into RDAP or DNS instead, as those resources are not linked to compromised web resources themselves

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Jan 2019 13:22:50 +0000

>    TLS supposed to prevent? The server is already compromised (hence the need for the info) so it is easier to modify the source, then modify it in transit.
   
You are assuming that all notifications are equivalent and that they are all of the "you are completely broken" nature.  I am not.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 7 Jan 2019 09:20:08 -0500

Sent from my mobile device

> On Jan 7, 2019, at 8:22 AM, Salz, Rich <[email-masked]> wrote:
> 
> 

And if it’s another server in the domain that’s compromised rather than the server with this file, having the information available for contact is useful.

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.

Best regards,
Kathleen 
> 
> 
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Jan 2019 10:45:47 -0800

> 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.

strongly agree that improving contact and associated information is a
forever goal, and one we could take some steps on now.

but rich is right, doing so in a manner which could be trivially secured
but isn't is pretty silly.

randy

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 7 Jan 2019 23:05:49 +0000

I agree that better security contact information is an important problem and
an admirable goal.

And I agree that there are some threat scenarios where security.txt might
not be compromised and would be able to be relied upon.

However, there are also many where it would not be wise to rely upon it,
especially early in an investigation where the true extent of the compromise
or security issue may be unknown.  And I'm sure that the information would
inevitably end up being used by many people who lack the sophistication to
make a reasonable decision about the likelihood of the information being
trustworthy.

For that reason, I tend to think that security.txt is a rather nasty
footgun, and quite likely to make the situation worse instead of better.  I
think time is better spent discussing better solutions to the problem.

-Tim

> -----Original Message-----
> From: saag <[email-masked]> On Behalf Of Randy Bush
> Sent: Monday, January 7, 2019 11:46 AM
> To: Kathleen Moriarty <[email-masked]>
> Cc: Mark O <Mark.O=[email-masked]>; [email-masked]
> Subject: Re: [saag] Comments on draft-foudil-securitytxt-04
> 
forever
> goal, and one we could take some steps on now.
> 
but isn't
> is pretty silly.

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 7 Jan 2019 21:41:58 -0500

> think time is better spent discussing better solutions to the problem.

As of today, there are several places where someone desiring to
contact a security team would obtain such information:
1. WHOIS for a particular domain name or IP address.
2. Emailing "[email-masked]" as per RFC 2142.
3. Trying to locate a disclosure policy or document on the
organization's website.
4. Contacting a CERT or a third party such as HackerOne or ZDI, in
hopes that they have a better way to reach out to a particular
organization.
5. Trying to find someone who works in a security role at a particular
organization via social media such as LinkedIn, and reaching out
directly.
etc.

All of these approaches have their advantages and disadvantages, and
it seems that usually a combination of these actually gets the
reporter in touch with the correct person at an organization.

This proposal is addressing item #3 - all it is providing is a simple
way for an organization to publish a security reporting policy on
their website in a standard, machine-parsable way, and stored in a
standard location. It is certainly not claiming to be more secure than
that approach, but at the same time it not less secure than publishing
this information on a website directly like it is done today.

There are other similar entries in the .well-known registry that use a
similar approach of publishing something in a webspace in order to
achieve a security-related result. Some examples are keybase.txt,
acme-challenge, etc.

Yakov

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Jan 2019 22:05:17 -0800

> this information on a website directly like it is done today.

https is pretty widely deployed.  most of the searches you enumerated
are tls protected today.  this proposal goes against that for no good
reason.  if this is not fixed, on last call i will stand with tim and
just shoot the damned horse.

randy

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Jan 2019 19:39:27 -0500

> just shoot the damned horse.

This does not make sense to me. If you are presenting security.txt for an HTTP
resource, it will naturally be served over HTTP, not HTTPS. The whole point
of this thing is that it is present on the resource itself, not somewhere else[.*]

If http://example.com is compromised, and you grab http://example.com/security.txt,
then whether the content of security.txt points to an HTTP or HTTPS resource is
meaningless.

You already lost on the initial unprotected download of security.txt (be it by
server compromise or active network attacker)

You can't have your horse and shoot it too.

Paul
[*] If you want the security of "somewhere else", you should have started to
look there in the first place.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Jan 2019 19:57:16 -0500

> 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 reduc…

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Jan 2019 17:06:59 -0800

> 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

randy

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 8 Jan 2019 21:01:40 -0500

On Tue, Jan 8, 2019 at 7:39 PM Paul Wouters <[email-masked]> wrote:
...
> then whether the content of security.txt points to an HTTP or HTTPS resource is

I want to clarify one point that Ed Foudil discussed with me: are we
assuming that this proposal is intended for *vulnerability disclosure*
or for *incident response*? Specifically, as per CERT's guide (section
1.2.8):
https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf

"Sometimes the term “Incident Response” is used synonymously with
Vulnerability Response. These two concepts are related, but different;
Vulnerability Response specifically indicates responding to reports of
product vulnerabilities, usually via the CVD process, whereas Incident
Response is more general and can also include other security events
such as network intrusions."

This proposal originates from the security research community and is
geared towards vulnerability disclosure, and not necessarily things
like reporting an active compromise - although it can be used for that
purpose. Perhaps that's where the disconnect is.

Yakov

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Jan 2019 09:45:52 -0500

> 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