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

[Yakov Shafranovich <[e-mail]>]

(Apologies on my delayed reply)

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

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

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.

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

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

>
> 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:
[snip]
> >
>
> > 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.
>

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

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

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.


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

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.

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

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.