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

From: Mark O <[email-masked]>
Date: Wed, 19 Dec 2018 13:16:12 +0000

I would like to see draft-foudil-securitytxt progress and support its publication in an amended format.

On balance this draft will help to improve the reporting and correction of vulnerabilities on servers and improve security for users and operators of servers. I recognise that there are some valid concerns over authentication of security.txt, particularly when the server has been compromised. In that scenario, it will not be possible to trust the information provided in security.txt. These concerns can be partially mitigated by using a secure transmission method such as TLS (v1.2 or v1.3). This improves the security around provisioning security.txt and, although this is an imperfect solution, I believe that overall the benefit to be gained from easier reporting of vulnerabilities outweighs the potential danger of incorrect information being provided by a malicious security.txt on a compromised server. When security.txt is used to find the reporting details for a vulnerability in a product produced by a vendor, rather than in the server itself, we can assume that the contents of the security.txt can be trusted and therefore there is no danger in using security.txt.

NCSC is keen to promote the usage of security.txt on UK public sector web servers as a method of providing contact information for responsible disclosure of vulnerabilities. NCSC would incorporate usage of security.txt into its "Web Check" service, a website configuration and vulnerability scanning service available to all UK public sector organisations.

I would like to see a change to the draft that mandates the use of a secure transmission method for security.txt. In practice this will mean the use of HTTPS over TLS or in future HTTPS over QUIC (HTTP/3). So Section 3.1 ("Scope") should state that security.txt MUST only be served over HTTPS (and the examples given using 'http://' should be removed from the text). Protecting the whole website using TLS is good practice and provides a level of assurance that the contents of the file have not been tampered with, either at rest on the server or in flight by a network adversary. There is a residual risk that the server has been compromised and therefore that the contents of the file are malicious; this is recorded in the "Security Considerations" section. This residual risk can be reduced through the use of a digital signature on security.txt (e.g. using PGP) or by recording contact details in DNS records, but these solutions also bring complications (root of trust for PGP key? can DNS data also be compromised?) therefore mandating a particular additional authentication appears to be counter-productive and would hinder adoption of an otherwise simple RFC.

I would additionally propose that, where the 'Contact:' directive is used to specify an email address using the 'mailto:' syntax, then it is necessary to also specify an encryption public key (via the 'Encryption:' directive) for protection of email messages sent to that contact address. So Section 3.4.3 should specify that the Encryption: directive MUST be used when the content of the Contact: directive is an email address. The specification cannot mandate that security researchers use encryption on email sent to this address - that would be out of scope - but an encryption key must at least be available. In practice this will mean a PGP public key is published on the web server or a separate key server, but security.txt should not mandate the format or the contents of the public key file.

Some specific review comments on the -04 draft:
* Replace "companies" by "organisations" throughout.
* Section 3, replace "alway" by "always"
* Section 3.4.2, replace "it MUST be begin" by "it MUST begin"
* Section 3.4.3, replace "it MUST be begin" by "it MUST begin"
* Section 3.4.4, replace "it SHOULD be begin" by "it SHOULD begin"

Some further comments on Paul Wouters' outstanding concerns in-line below.

On Thu, 23 Aug 2018 15:16:07, Paul Wouters wrote:
>
> 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.

The amount of detail included on the security acknowledgments page is entirely at the discretion of the server's administrator; security.txt does not mandate that specific vulnerabilities are disclosed. It is obviously undesirable to include information on the security acknowledgments page that would lead an attacker to scan for a particular vulnerability or try a particular attack.

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

Agreed that if the server is compromised to the extent that files can be added/modified/deleted then the contents of security.txt cannot be trusted. This can be partially mitigated by adopting good security practices including the use of TLS and a signature on the file using an externally verifiable public key. Ultimately there is a balance to be made between providing appropriate protection to the server and security.txt, and the usability and utility of security.txt for reporting security vulnerabilities, and this balance may differ between use-cases.

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

Would it be better to point to best current practice on the use of TLS for securing servers, e.g. RFC 7525? HTTPS still brings benefits over HTTP because an unauthenticated connection could be subject to a man-in-the-middle attack to serve a fake version of security.txt, even without compromising the server.

NCSC has published an article on why HTTPS matters:
https://www.ncsc.gov.uk/blog-post/serve-websites-over-https-always
Google also have a good article on the same topic:
https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https

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

HTTPS provides a baseline level of protection, but does not protect against all threats (the server could have been compromised). It is good practice to use an external method for verifying the authenticity of the contact, but this is outside the scope of what can be specified within security.txt.

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

This is one way of building trust and a sense of community with vulnerability researchers to encourage responsible disclosure, but its presence in this specification should be entirely optional.

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

This document should not mandate any particular format for a signature, including whether it is inline or external.

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

Any solutions proposed will be imperfect because of the possibility of fake data being written to a compromised server (or DNS record, or TLS certificate). This proposal for security.txt is a pragmatic way forward that will be beneficial in the majority of cases and provides a basis for a more formal responsible vulnerability disclosure process.

-- Mark

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 25 Dec 2018 22:58:22 -0500

(Apologies on my delayed reply)

> NCSC is keen to promote the usage of security.txt on UK public sector web servers as a method of providing contact information for responsible disclosure of vulnerabilities. NCSC would incorporate…

Your support is appreciated

>
> I would like to see a change to the draft that mandates the use of a secure transmission method for security.txt. In practice this will mean the use of HTTPS over TLS or in future HTTPS over QUIC (HTTP/3). So Section 3.1 ("Scope") should state that security.txt MUST only be served over HTTPS (and the examples given using 'http://' should be removed from the text). Protecting the whole website using TLS is good practice and provides a level of assurance that the contents of the file have not been tampered with, either at rest on the server or in flight by a network adversary. There is a residual risk that the server has been compromised and therefore that the contents of the file are malicious; this is recorded in the "Security Considerations" section. This residual risk can be reduced through the use of a digital signature on security.txt (e.g.. using PGP) or by recording contact details in DNS records, but these solutions also bring complications (root of trust for PGP key? can DNS data also be compromised?) therefore mandating a particular additional authentication appears to be counter-productive and would hinder adoption of an otherwise simple RFC.
>

A similar point has been raised by our document shepherd (Kathleen
Moriarty) and as per her suggestion we changed all of the "http://"
examples in the draft to "https://" as well as changed the language to
read "RECOMMENDED" in regards to HTTPS. Based on our discussion it
felt that using MUST may be unrealistic in the real world. These
changes have been made in the GitHub version but not yet published -
they will go into the -05 version:
https://github.com/securitytxt/security-txt/blob/master/draft-foudil-securitytxt.txt

> I would additionally propose that, where the 'Contact:' directive is used to specify an email address using the 'mailto:' syntax, then it is necessary to also specify an encryption public key (via…

I am opening an issue on GitHub to track this:
https://github.com/securitytxt/security-txt/issues/134

Similar to the point above regarding TLS support, I am not sure if
MUST would work. Do you think RECOMMENDED or a SHOULD would be
sufficient here?

Regarding the key format, several implementers have reached out and
asked for clarification. The context is that people want to build
automation around the parsing of these files and feel like knowing the
format of the key is useful. We have been considering a possibility of
explicitly spelling out PGP as the default key format and adding an
optional field to indicate a non-PGP format, or perhaps leaving this
field for the future to be added to the IANA registry if it becomes
needed.

> * Section 3.4.2, replace "it MUST be begin" by “it MUST begin”
>
> * Section 3.4.3, replace "it MUST be begin" by “it MUST begin”
>
> * Section 3.4.4, replace "it SHOULD be begin" by “it SHOULD begin”
>

I am filing an issue to track this and will review:
https://github.com/securitytxt/security-txt/issues/135

> > On 07/16/2018 04:32 PM, Yakov Shafranovich wrote:
[snip]
> The amount of detail included on the security acknowledgments page is entirely at the discretion of the server's administrator; security.txt does not mandate that specific vulnerabilities are discl…

Perhaps adding language explicitly spelling this out would help as well?

> > "https://”

As per my comment above, the language in the upcoming -05 draft has
been changed to "RECOMMENDED". I think we can also add some of these
concerns to the security concerns section in the draft.

> This is one way of building trust and a sense of community with vulnerability researchers to encourage responsible disclosure, but its presence in this specification should be entirely optional.

The only required field in the file is "Contact", all other files
including this one are optional. Additionally, as per the IANA
registry being defined with this draft, if this particular directive
proves harmful or ends up not being used, it can demoted to
"deprecated" or "historic" status. As per my original comments, this
field is being used by those implementing "security.txt" and we are
documenting existing usage.

> This document should not mandate any particular format for a signature, including whether it is inline or external.

There has been ongoing discussion around this piece, especially since
several parties want guidance on parsing. Additionally, the way the
ABNF grammar is defined now it doesn't account for inline signatures.
At this point, the feedback we got seems to indicate that support for
both inline and detached signatures is useful, plus mandating the
presence of the detached signature file to be always in the same
location.

---

From: Mark O <[email-masked]>
Date: Mon, 31 Dec 2018 16:55:25 +0000

> A similar point has been raised by our document shepherd (Kathleen Moriarty) and as per her suggestion we changed all of the "http://" examples in the draft to "https://" as well as changed the language to read "RECOMMENDED" in regards to HTTPS. Based on our discussion it felt that using MUST may be unrealistic in the real world. These changes have been made in the GitHub version but not yet published - they will go into the -05 version

Thanks for pointing me to the -05 draft. We would strongly prefer that HTTPS 'MUST' be used as this ties in with the advice we offer to administrators of public sector websites, however, 'RECOMMENDED' would not prevent us using security.txt.

> Similar to the point above regarding TLS support, I am not sure if MUST would work. Do you think RECOMMENDED or a SHOULD would be sufficient here?

Vulnerability researchers need to have a secure method of communicating with the contact specified in security.txt, and unencrypted e-mail cannot be regarded as secure. A contact telephone number would be better than unencrypted e-mail. If a public key is not mandated here, then I expect in practice it will not be supplied and only an insecure e-mail address will be given. This leaves the vulnerability researcher no option but to send unencrypted, insecure e-mail.
How about, specifying that at least one *secure* Contact address MUST be provided, which could be an e-mail address with corresponding public key, a URL for a web form served over HTTPS, a telephone number, a postal address, an instant messenger account... but also being explicit that unencrypted e-mail is not considered secure and therefore must not be the only contact method listed.

> Regarding the key format, several implementers have reached out and asked for clarification. The context is that people want to build automation around the parsing of these files and feel like knowing the format of the key is useful.

I feel that being prescriptive about a key format (also a signature format) could become a barrier to adoption. Furthermore I would have thought that the use-case for automated parsing of security.txt would be very limited - in most cases, I expect the way that this file will be used is that a researcher will find a vulnerability and then check for the existence of a security.txt file to find the contact details of who to report it to - i.e. a very manual, non-automated process. We want to make it as easy as possible to publish a security.txt file, not to scrape them for details.

> Perhaps adding language explicitly spelling this out would help as well?
Yes, it's probably necessary to explicitly point this out.

-- Mark

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Dec 2018 20:05:06 +0000

I think it is silly to have an automated security.txt that doesn't have TLS.

---

From: Randy Bush <[email-masked]>
Date: Mon, 31 Dec 2018 12:23:03 -0800

> I think it is silly to have an automated security.txt that doesn't

agree, but i lost that discussion a year ago.  i decided to just not
take this docco seriously.