Re: [secdir] Secdir last call review of draft-foudil-securitytxt-08

[Yakov Shafranovich <[e-mail]>]

On Tue, Dec 24, 2019 at 10:51 AM Tero Kivinen via Datatracker
<[e-mail]> wrote:
> Reviewer: Tero Kivinen
> Review result: Has Issues
>
> This document describes text file located in the web server which can be used
> to find the information where to contact in case there is security
> vulnerabilities that needs to be disclosed.
>
> I think this whole idea is BAD, and I do not think we should be publishing this
> document at all in this format.
>
> First of all, the description here says we are providing "machine-parseable and
> extensible way for organizations to communicate information about their
> security disclosure policies". This file is supposed to be used WHEN there is
> security vulnerability found in the site, and in that case the attacker might
> have already had a way to modify this file too.

The draft is not intended to be used for reporting issues related to
an active incident as described in previous discussions. There is a
subtle but important difference between incident response vs.
vulnerability response. See:
https://mailarchive.ietf.org/arch/msg/last-call/ZIftviNdfGbdzruvvffG3KuCcQs
https://mailarchive.ietf.org/arch/msg/last-call/YDa3P3SnnXaEPG7Vm8noDUlS38U
https://mailarchive.ietf.org/arch/msg/saag/zl7ZFk4esY-O-q6qHLgErVThvbE

This is also why section 1 of the draft calls out other guidance such
as ISO 29147 and CERT CVD. We can certainly make this more explicit.

> Because of this I think
> providing machine-parseable format is bad, as this can open new security
> vulnerabilities, when some security problem reporting software parses this file
> generated by the attacker. Another problem is that even if the parser which
> parses this properly verifies the contents, the attacker might have changed the
> reporting locations to [e-mail] or similar address, and if this
> report is semi-automatically sent the security reporter might not realize that
> he is just sending reports to the attacker.
>

Regarding the parsing issue, this is true for any machine readable
format on the Internet. This is there is extensive discussion in
section 6 around these issues.

> If this kind of file is needed, I think it should be human readable, and only
> shown to the user making the report, and user should then read it and find out
> the information where to send the reports. This way there is human in the
> process verifying that the information provided by the security.txt file is
> sane.
>

Human triage is recommended as described in section 6.7. We can make
this recommendation stronger.

As an aside - this has been intended as a lightweight solution which
is both parsable and human readable. We didn't want to make a complete
arbitrary file format since it wouldn't really have any meaning, and
by restricting what can appear in it, it leads implementers towards a
reasonable list of things that should and should not be done. On the
other hand, we didn't want to put too many things in it since it would
make the file to hard to create and use. People are also designing
tooling around this.

> More detailed comments follows.
>
> In section 3 it says that "security.txt" SHOULD be placed in the /.well-known/
> path for web properties. Why is this not MUST? For this to be usable standard,
> there must be one location which is the authorative for this file. I think this
> document needs to say that it MUST the in /.well-known/security.txt.
> Documenting the legacy location in /security.txt is ok, and applications might
> try to read that also in case the standard "/.well-known/security.txt" is not
> found. Also it should tell which file is used if multiple copies of
> security.txt is found and their content is different.
>

The only reason why it says SHOULD now was due the legacy mechanism
and my understanding is that using MUST would prohibit the legacy
mechanism all together.

For multiple copies, the one in .well-known path will take precedence
but we can make this more explicit.

> Also it seems even this document is not clear whether this is machine-parseable
> or not. It says it must be text/plain, and has .txt in file name, which would
> indicate it is just text file, not machine-parseable file. If the real reason
> is to provide machine-parseable file then .json / .xml or some other really
> machine-parseable file would be more suitable. On the other hand it also says
> in several places that security researcher SHOULD check this file and verify
> that everything looks good and so on. So if human is always needed in the loop,
> why even try to make this file machine-parseable. We can use the same format
> even if we do not try to make this file machine-parseable as humans also
> benefit from having standardized format containing information they need.
>

Not clear on the concern here - it is intended to be machine readable
since humans will build tools around it. The human triage will take
place before report submission but there are a lot of other things
tools can do prior to that. Additionally, we didn't want people to
dump anything they wanted into it.

The reason why ".txt" and headers were used since it was meant to be
an easy to read format and based off "robots.txt", so anyone can
easily create such file without resorting to XML or JSON.

> Section 3 also says that "A security.txt file can have an unlimited number of
> fields." is bit dangerous when there is good probability that this file is
> generated by attacker. Perhaps provide some suitable limits for the size of
> this file. As most of the directives only provide pointers to another places,
> it might be suitable to limit this file in some sane size, for example saying
> that it SHOULD be less than 64kB, and receiver do not need to parse files
> larger than 1MB in size. These limits could also be added to section 6.3 if not
> here.
>

Section 6.3 says "extraordinarily large" but we can certainly add a
specific size as an example.

> Section 3.2 says that "Only the line most immediately preceding a field SHOULD
> be associated with that field." meaning that if you have file saying:
>
> # Our security policy is provided in the separate domain because the external
> # company was used to generate it
> Policy: https://example.com/security-policy.html
>
> and this would only associate the 2nd comment line to the Policy field. This
> can cause unexpected results for people generating this file, as usually they
> assume that you can add multiple lines of comment and all of them relate to the
> next field.
>

This is why it's only a SHOULD and not a MUST. Some context here:
https://github.com/securitytxt/security-txt/issues/158

> In section 4.1, why is the redirect processing forbidden only when security.txt
> is in top directory, i.e., in that case the redirect will not be followed if it
> is not in the same server? Why do we allow redirects from the
> /.well-known/security.txt to external domains or servers? I would remove the
> 2nd paragraph of 4.1 completely, or rewrite it so it covers all cases where
> security.txt is fetched. The security section 6.1 claims that "/" is more
> likely to be compromised than "/.well-known/" and thats why redirects are
> limited for those, but redirects can also be done in the httpd server
> configuration file, and in that case it does not matter whether it redirects
> /.well-known/security.txt or /security.txt. Also I do not think there is real
> difference which directory is compromised more easily. If attackers can file
> files to the filesystem served by the web-server they quite often can do that
> for all paths.
>

The feedback we received on the draft so far has been that people feel
that the root directory is more likely to be compromised. On the other
hand, the following of redirects has been an important operational
requirement at organizations where multiple domains may all be
pointing to the same master "security.txt" file located on a primary
corporate domain.

One solution to address this is to allow redirects in all cases but to
add a stronger warning in section 6 regarding where they may lead and
that the parsers should be more careful with redirects across domains
vs. a redirect on the same domain. We had discussions around this and
there was no clear consensus, which is why this compromise is listed.

> How is section 4.3 and 4.2 different. The root directory of the internal host
> is usually also considered as filesystem, so the rules of 4.2 also cover 4.3.
> Also why it is important that security.txt is put to the root directory of the
> filesystem only on internal hosts, but not in external hosts?
>

The filesystem and internal hosts sections are intended for use cases
where a researcher has gained access to systems which which might not
be web servers. So for example, if an SSH host is compromised, the
"well-known" path would make no sense.

> This document contains lots of SHOULD etc to the actual users of the files
> (security researchers, organizations etc), which is bit funny. It is quite hard
> to verify that security researchers really checks the file before using it. It
> is good thing to give useful instructions for the users, but making them SHOULD
> or SHOULD NOT is not really helpful.
>

We were basing this on the guidance in RFC 2119, section 6:
"In particular, they MUST only be used where it is actually required
for interoperation or to limit behavior which has potential for
causing harm"

Specifically, "to limit behavior which has potential for causing harm".

> In section 6.6 it says we MUST validated the X.509 certificates of the TLS, but
> one of the most common security reports I have been doing is a report of the
> expired certificates, in which case the certificate of the site serving
> security.txt is also expired, thus to be able to find this I need to allow
> reading this even when certificate validation failed.
>

Based on previous discussion on the SAAG list, many members felt very
strongly that in today's Internet SSL is a MUST. The feedback we
received so far doesn't seem to indicate that reporting expired
certificates is all that common. However, we can spell out this use
case with additional guidance that if the issue being reported is for
SSL itself, researchers should rely on other mechanisms such as the
digital signature.

> I wonder do we really need Hiring and Acknowledgements directives? I do not
> think they are really needed by the security researcher sending reports...
>https://mailarchive.ietf.org/arch/msg/last-call/ZIftviNdfGbdzruvvffG3KuCcQs

Both are documenting existing usage - they are in active use.

Thanks