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

[Tero Kivinen <[e-mail]>]

Yakov Shafranovich writes:
> 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.

Yes, but this is data that I would always assume has been modified by
attacker. The difference is not large, but it is similar than what is
required by firewall code versus networking stack of the normal
operating system.

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

If human is always recommended when do you think this would be used
automatically and where would the machine-parseable aspect of this
document be required?

I mean we can keep the exactly same format, but just remove all text
relating to the machine-parseable from the draft. The document will
still stay as machine-parseable as it was before, but it would give
much more emphasis that this do require human interaction. 

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

I am bit concerned about the need for tooling for this file. Why do
you think we need tooling. Is there really going to be so many
vulnerabilities found in general that such tooling is required. My
take would be that security researcher would simply cut & paste the
contact information from this file and use that, and that is the
tooling required. Or directly click the link in policy keyword to read
that ect.

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

No. Those legacy mechanisms could not then claim to be following this
RFC to be until move the file location to correct place. Saying that
the file MUST be at /.well-known/security.txt does not forbid having
that file in other locations too, and does not have any effect on the
legacy systems. 

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

I did not find that text at all, so yes, make it 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.

What kind of other things tools can do prior to that? What is expected
to happen with those tools. Why do we even need the tools. What kind
of software you assume will be reading this file and act based on 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.

Yes, I can understand it being .txt file if it human readable. If it
is supposed to be machine readable, then it will most likely be
machine generated also, meaning any proper machine parseable format
would be better than this one.

Robots.txt is very bad example, as that file is always machine
readable, there is no reason for humans to read that ever. That file
should be in some more sane format than .txt file.

To summarize, I think this document should only be meant for humans to
read, and because of that I think we should keep the format and the
.txt format, but we should remove the mentions in the draft that
suggest that this is read by tools or to be machine-parseable.

Of course it will still stay machine-parseable as same format and same
ABNF will be used, but as this is not intended to be machine readable,
we do not need to emphasize that.

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

Different people do have different meaning of extraordinary large.
Some people would consider my examples of 64kB/1MB way too big, and
some would consider them still tiny (when normal web page to download
is several tens of magabytes then 64kB seems like very small).

Yes, I think it would be good idea to provide some specific limits.

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

This whole issue goes away if we do not assume this is
machine-readable but assume it is read by human. Human can very easily
associate comments to suitable keywords.

I would simply remove the whole text talking about comment and
associated fields.

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

I can see the reason for redirects, I do not really see that big
difference of root or /.well-known directories.

In both cases to make redirect you usually need to make .htaccess file
in that directory or to change the configuration of the web server. 

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

If this is human readable file format then the tool to fetch this will
be web browser or wget or similar. Those will follow readirects
automatically and what we say here does not really matter.

One of the problem with redirects is that Canonical is field that can
only appear once, thus there is no way to verify that this
https://example.com/security.txt file should really be something that
should be used when you go there with redirect from
https://signin.example.com/security.txt.

If there could be multiple Canonical fields then you could list all
the possible locations where this same file could be found, while all
of them redirect them to this location. 

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

Yes, but then I would assume that the security.txt would be in the
root directory of that machine, i.e., the section 4.2 would be the one
that applies. So I would simply just remove section 4.3, as I think
4.2 already covers that.

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

How are you going to verify that security researches and organzations
are going to follow your SHOULDs?

I have received question from the customer (from Japan) where they
listed all SHOULDs, MUSTs, and MUST NOTs in the RFC and required to
know which line numbers of our code implement those requirements. For
SHOULDs and MUSTs it sometimes is easy, but for "Implementation MUST
NOT do XXX" is bit harder to pinpoint the exact line numbers NOT doing
XXX...

If you have SHOULD or MUSTs which cannot be verified at all, or which
depend on the humans, they are always something that is problematic.
For example in IPsec we tried to be very clear that we do not for
example say that users MUST NOT configure their IPsec to use DES, we
said implementations MUST not implement DES.

There is no point of saying for example this:

   Organizations SHOULD ensure that information in this file and any
   referenced resources such as web pages, email addresses and
   telephone numbers are kept current, are accessible, controlled by the
   organization, and are kept secure.

Using SHOULD there does not help at all. Changing that to say
"Organizations needs to ensure that ..." would meant that person who
is implementing this will not try to implement that SHOULD...

> > 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 have reported expired certificates twice this year already, and both
of them did got fixed in few days after my email... With Lets Encrypt
this is going to be more and more common in the future.

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

As this is extensible format and humans known how to skip over unknown
fields anyways it does not matter whether they are in use or not. Do
we really need those fields in the format. What benefits they have?
What use they are for the security researcher using this file?

Yes, he could use the Acknowledgements directive to verify that his
report is properly acknowledged in that file, but hiring should most
like use some other channels than security.txt.

Especially the hiring directive information will most likely be out of
date very quickly so it does not go very well with the requirement
that organations SHOULD keep it up to date....
-- 
[e-mail]