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

[Yakov Shafranovich <[e-mail]>]

On Fri, Dec 27, 2019 at 6:34 PM Tero Kivinen <[e-mail]> wrote:
>
> Yakov Shafranovich writes:
> > On Tue, Dec 24, 2019 at 10:51 AM Tero Kivinen via Datatracker
> > > 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.
>

Would making the language in the security section stronger help with
this? Right now we say the following:

"Implementers should make sure that any such code is robust against
large or malformed files and fields and may choose not to parse
files larger than 32 KBs, having fields longer than 2,048 characters
or containing more than 1,000 lines."

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

I will remove the machine-parseable references

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

I will change this to MUST

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

Will do

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

I will remove the machine-parseable language

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

Added this:
Implementors SHOULD make sure that any such code
is robust against large or malformed files and fields and may choose
not to parse
files larger than 32 KBs, having fields longer than 2,048 characters or
containing more than 1,000 lines.

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

Will do

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

Will address this

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

That is an excellent idea, I will adjust the language to indicate that
multiple "Canonical" fields can appear.

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

Will do

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

We are going to remove the RFC 2119 keywords where it makes sense

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

How about adding this language:

"In cases where the "security.txt" file cannot be served via HTTPS or is
being served with an invalid certificate, additional human triage is
recommended since
the contents may have been modified while in transit."

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

Acknowledgements directive is used by researchers when deciding
whether to report something or not. Some researchers would not report
a low severity vulnerability unless there is such page.

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

Organizations find it useful which is why we included it. Even if it
is not included now, it will probably get submitted to the IANA
registry anyway.

Thanks