Subject: Re: [saag] Fwd: New Version Notification for draft-foudil-securitytxt-04.txt

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Aug 2018 15:16:07 -0400

On 07/16/2018 04:32 PM, Yakov Shafranovich wrote:

> A new version of I-D, draft-foudil-securitytxt-04.txt
> has been successfully submitted by Edwin Foudil and posted to the
> IETF repository.
> URL:
> https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-foudil-securitytxt/
> Htmlized:       https://tools.ietf.org/html/draft-foudil-securitytxt-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt-04

All my existing concerns still  applies and it might even be worse now.

Section 3.4.1 basically suggests building a list of fixed vulnerabilities with the acknowledgments section. So now hackers can scan for which servers haven't
been patched for something. Especially valuable if 9 out of 10 servers in the company have some acknowledgment but one of these does not.

3.4.3 is still terrible. If a server is compromised and security.txt is changed to the hackers PGP key, then ONLY the hackers are informed if someone is close
to catching them. The real operators wont even be able to read the message.

And this advise does not belong in an IETF document:

	If this directive indicates a web URL, then it MUST be begin with "https://"

with the entire world being https, this gives a false sense of security. The paragraphs also forms a nice Inception loop. What is the host that is hosting
the security key itself publishes a security.txt file. And why does it even matter in the first place if it is http or https, unless the person who found
the compromised website themselves are compromised?

   When it comes to verifying the authenticity of the key, it is always
   the security researcher's responsibility to make sure the key being
   specified is indeed one they trust.

So we pretend to offer a new "secure" method for finding a security contact, then say "dont ever trust this". So why specify this at all?

3.4.4 Hiring ?

What are we now. a new Linked In protocol extension ?

3.4.7 signature file

I have no idea why it has to be external and not inline, which is the typical PGP/GPG way

6 Security Considerations

To me this reads like all the reasons why all of this is a bad idea. But now people like me who would never deploy this need to be aware of all of
this because my compromised server might add a security.txt file misleading people so they will never contact me. It's a burden on those who don't
want to implement this unwise idea.

Anyway, the essence still remains. If I find a hacked server, I should not trust that server for anything in provides. Instead, I should find another
resource that will hopefully still be trustworthy to find a contact. A number of superiors ways:

- Mail to the dns contact(s) of the domain based on SOA record email or WHOIS/RDAP data
- Mail to the contact configured in the 40x errors on the http server (lets hope hackers only got into /var/www and not /etc/httpd)
- google "security <domain name>"
- go to linked in, find someone in IT in that company and ping them
- find a twitter account or facebook page of the company
- check any of the security groups/cabals ( eg ops-trust)

All these methods are more trustworthy then a text file on a compromised server. And even the draft says to not trust it so you end up having to do
one of these anyway. So I don't see it add any value at all.

And if I was a hacker that compromised the server, I would surely delete or modify this file, or make it throw an error serving it.

Another alternative approach is to add a field to the webservers certificate that contains a contact email/phone field. An attacker won't be able
to modify this data without killing the certificate's CA signature. But that might be less useful now than in the past if the attacker can just ACME a new one.

I still think this document should not move forward, and believe it might cause more damage instead of making finding security contacts more reliable.

Paul

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 23 Aug 2018 20:54:59 -0400

Draft:
https://www.ietf.org/id/draft-foudil-securitytxt-04.txt

> been patched for something. Especially valuable if 9 out of 10 servers in the company have some acknowledgment but one of these does not.

I am confused here. An acknowledgment section doesn't usually list the
actual vulnerabilities, it just thanks people. Here are some examples:
https://www.google.com/about/appsecurity/hall-of-fame/
https://access.redhat.com/articles/66234
https://www.microsoft.com/en-us/msrc/researcher-acknowledgments-online-services

Even the example in the draft is using very generic language like "SQL
injection or "server configuration issue" without actually specifying
enough details for someone to attack further.

Are you suggesting that this section be removed, or is your concern
specifically with the example provided?

> to catching them. The real operators wont even be able to read the message.

We are still working out details around both the digital signature on
the file itself and the encryption key it is pointing to.

> the compromised website themselves are compromised?

This is included because this field is a URI and that reference a DNS
record or a fingerprint as seen in the examples provided in the draft.
The intent is specifically to say that you should use SSL for the web
URIs, since HTTPS won't make sense in the context of other protocols.

> What are we now. a new Linked In protocol extension ?

This is documenting existing usage. Once companies started adopting
the standard they were adding this header in, and we wanted to simply
document it.

> I have no idea why it has to be external and not inline, which is the typical PGP/GPG way

We are currently discussing this as well. The original thought behind
having an external key was intended as a way to make this extensible
enough so it can support other signature schemes in the future. But
there is probably a way to make this work inline while keeping this
extensible.

> resource that will hopefully still be trustworthy to find a contact. A number of superiors ways:

If someone compromises a webserver, security.txt is probably not
something they would be targeting.

> one of these anyway. So I don't see it add any value at all.

Having been on both sides of the disclosure process (sending reports
and receiving them), I can say that none of the current ways to figure
out whom to contact work well. The intent of this document is very
specific - it is intended to essentially make a machine-readable
equivalent of a "security HTML" page and place it in a standard
location of a webspace. From the feedback we have received so far, it
seems that placing a file in a webspace seems to be easier than doing
DNS. RDAP or email because the various teams are often not the same
ones as the ones handling security reports.

> to modify this data without killing the certificate's CA signature. But that might be less useful now than in the past if the attacker can just ACME a new one.

That is true for a lot of the other methods described above as well.
One of the things we are exploring is having monitoring of these
files, conceptually similar to the certificate transparency. It is
also an open question of what is the actual likelihood of this
happening in the real world and the risk vs. the value provided by
this proposal.

> I still think this document should not move forward, and believe it might cause more damage instead of making finding security contacts more reliable.

Thank you for your feedback, it is appreciated.