Skip to main content

Last Call Review of draft-foudil-securitytxt-08
review-foudil-securitytxt-08-secdir-lc-kivinen-2019-12-24-00

Request Review of draft-foudil-securitytxt
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-01-06
Requested 2019-12-09
Authors Edwin Foudil , Yakov Shafranovich
Draft last updated 2019-12-24
Completed reviews Secdir Last Call review of -08 by Tero Kivinen (diff)
Genart Last Call review of -08 by Roni Even (diff)
Assignment Reviewer Tero Kivinen
State Completed
Review review-foudil-securitytxt-08-secdir-lc-kivinen-2019-12-24
Posted at https://mailarchive.ietf.org/arch/msg/secdir/FRwZBR_9C9xQXXAyyNbxkRhinSw
Reviewed revision 08 (document currently at 12)
Result Has Issues
Completed 2019-12-24
review-foudil-securitytxt-08-secdir-lc-kivinen-2019-12-24-00
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. 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 devnull@example.com 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.

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.

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.

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.

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

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.

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?

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.

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.

I wonder do we really need Hiring and Acknowledgements directives? I do not
think they are really needed by the security researcher sending reports...