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 rev. no specific revision (document currently at 09)
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 rev. 08 (document currently at 09)
Review result Has Issues
Review completed: 2019-12-24

Review
review-foudil-securitytxt-08-secdir-lc-kivinen-2019-12-24

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