Subject: [Last-Call] Secdir last call review of draft-foudil-securitytxt-08

From: Tero Kivinen via Datatracker <[email-masked]>
Date: Tue, 24 Dec 2019 07:51:17 -0800

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. 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 [email-masked] 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...

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 25 Dec 2019 21:59:49 -0500

On Tue, Dec 24, 2019 at 10:51 AM Tero Kivinen via Datatracker
<[email-masked]> wrote:
> 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

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.

> process verifying that the information provided by the security.txt file is

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.

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

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

> larger than 1MB in size. These limits could also be added to section 6.3 if not

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

> assume that you can add multiple lines of comment and all of them relate to the

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

> files to the filesystem served by the web-server they quite often can do that

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.

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

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

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

>https://mailarchive.ietf.org/arch/msg/last-call/ZIftviNdfGbdzruvvffG3KuCcQs

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

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 28 Dec 2019 01:34:36 +0200

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

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

> make the file to hard to create and use. People are also designing

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.

> and my understanding is that using MUST would prohibit the legacy

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. 

> but we can make this more explicit.

I did not find that text at all, so yes, make it more explicit.

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

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

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

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

> pointing to the same master "security.txt" file located on a primary

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. 

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

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

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

> SSL itself, researchers should rely on other mechanisms such as the

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.

> 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....
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 27 Dec 2019 19:22:20 -0500

> On Dec 27, 2019, at 18:34, Tero Kivinen <[email-masked]> wrote:
> 
> 

It is worse. A company MUST always be seen as growing, so even if they are not hiring, some bogus information will be provided here, similar to the “mandatory” statement on their website regarding hiring.

Paul

---

From: Edwin Foudil <[email-masked]>
Date: Sat, 28 Dec 2019 14:01:52 +0100

> tooling required. Or directly click the link in policy keyword to read

There is already a demand for tooling by the public; this was not necessarily something we (the authors) came up with. Some of the published tooling developed by members of the public can be found here: https://securitytxt.org/projects.
Also, as others have already pointed out in this mailing list, Shodan (https://www.shodan.io/) and disclose.io (https://disclose.io/) index contact information from security.txt files.
Since there is already tooling out there, I think it is safe to say that people do not necessarily want to extract information from a security.txt file manually.
> in that directory or to change the configuration of the web server.

I can back our statements up with real-world cases. I am a bug bounty hunter and actively go after namespace attacks. This attack vector abuses the fact that most applications with users reserve the top-level directory for usernames. Some of my findings include redirects to external pages from /<username>. In addition, all of the cases I have found did not require access to the web server itself.
Please refer to https://edoverflow.com/2018/logic-flaws-in-wot-services/ for a case demonstrating this attack vector in practice.
Applications that use the top-level directory for usernames can be vulnerable to namespace attacks. But I have yet to come across a compromised /.well-known/ directory: websites usually do not allow dot-prefix or directory-like usernames.
- Ed

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 28 Dec 2019 15:33:20 +0000

I don't understand the security concerns about "do not publish this."

It's protected by transport level security, and it's encouraged to use application-level signing.  It's machine readable, or easily parseable, and it makes it easier for people to report problems.  Do we have a problem with over-reportage?

Don't let the perfect be the enemy of the better.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 28 Dec 2019 11:56:36 -0500

> On Dec 28, 2019, at 10:33, Salz, Rich <[email-masked]> wrote:
> 

We did that already with Whois/RDAP ? It’s the non-perfect solution we have that is more secure than this alternative.

It’s not perfect, and rdap is better than Whois for human plus machine readable.

Putting this information in the same realm you have a security issue with is just not a good idea for many reasons mentioned during the entire discussion of the document and the various last call comments.

We have more less-perfect solutions too. There is the web server error message contact info too. The DNS SOA record has a contact. The main web page usually has a “contact” place listing an email or web form. And we have postmaster@ and info@ and security@ email address that usually work. If anything, we already have too many non-perfect solutions out there and this proposal is really a perfect example of xkcd 927.

Paul

---

From: Watson Ladd <[email-masked]>
Date: Sat, 28 Dec 2019 09:13:17 -0800

On Sat, Dec 28, 2019 at 8:56 AM Paul Wouters <[email-masked]> wrote:

> > It's protected by transport level security, and it's encouraged to use
> application-level signing.  It's machine readable, or easily parseable, and
> it makes it easier for people to report problems.  Do we have a problem
> with over-reportage?
> >
> We did that already with Whois/RDAP ? It’s the non-perfect solution we
> have that is more secure than this alternative.
>
> Putting this information in the same realm you have a security issue with
> is just not a good idea for many reasons mentioned during the entire
> discussion of the document and the various last call comments.
>

Most vulnerabilities will not get access to this file. Stuff like SQL
injection, CSRF, XSS, etc.

>
> We have more less-perfect solutions too. There is the web server error
> message contact info too. The DNS SOA record has a contact. The main web
> page usually has a “contact” place listing an email or web form. And we
> have postmaster@ and info@ and security@ email address that usually work.
> If anything, we already have too many non-perfect solutions out there and
> this proposal is really a perfect example of xkcd 927.
>

The reason this draft was made is those methods don't work. DNS SOA and
website contact can go the wrong places in an organization. info@ and
security@ aren't universal, and after that you're left being psychic. We
are seeing new solutions to serious problems, and the response is "No, it
isn't a problem" when the proposed solutions offer far less information.
You're also assuming that another place to put information is a bad thing,
and a possible heads up to a hypothetical attacker is worse then no
notification.

Right now the standard is begging on twitter for a chain of introductions.
We should be able to do better.

> Paul
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Dec 2019 10:44:31 -0800

> Right now the standard is begging on twitter for a chain of

and it works, i am embarrassed to say.  and one hears about outages on
the ops lists before one sees the automatic outage detector reports.
sitting across the hudson, i heard of the wtc attack on nanog almost two
minutes before it came on television.

these half-assed "the market demands something" panaceas provide false
solutions we have to clean up later; emphasis on that last clause.
rwhois anyone?  the highway is littered with whitepages roadkill.  today
there is a massive problem with authority in the IRR (which some RIRs
throw in with whois); and retrofitting a solution is now years in blah
blah blah.

no one is asking for the perfect over the good.  but it is our
obligation, before putting the ietf stamp on it, for it to be as good as
we can reasonably get for the time.  this proposal is not, as has been
enumerated time and again as it has been shoved through the process over
objections.

imiho, tero's review stands.

randy

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 28 Dec 2019 20:38:08 +0000

>    Putting this information in the same realm you have a security issue with is just not a good idea ...

It depends.  If someone uses the one at openssl.org, will they be reporting an issue in the libraries, the software, the website?  My money's on the first.  Similarly, if there were one at www.akamai.com, how would that be used?

>perfect example of 927

No, seems pretty clear that the others aren't as successful as we want/need.  Whois/rdap?  Who uses that?

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 28 Dec 2019 19:31:01 -0800

Hi Randy,

> minutes before it came on television.

I do hear many stories about twitter letting people get in touch with the
right organizational contact; a lot of them even "make the news" for some
definition of "news".  I wonder if they remain newsworthy because achieving
success is far from guaranteed, whether by "traditional" methods or by
twitter.

> imiho, tero's review stands.

I do note the second 'i', but I have to say that to me, "shoved through the
process over objections" sounds like a pretty serious process violation
that ought to be remedied.  I'd like to better understand what you see as
the process violation (if any) here, so that I can try to remedy it.  I
note that the IETF LC period is still open, and I am closely reading all
the feedback (e.g., including Paul Hoffman's note that arrived a bit after
yours) and will make an assessment of whether there is IETF consensus to
publish the document based on the feedback received during the last call.
(Which is to say, I do not consider consensus to be a foregone conclusion.)

Thanks,

Ben

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Dec 2019 21:38:36 -0800

>> and it works, i am embarrassed to say.  and one hears about outages
>> on the ops lists before one sees the automatic outage detector
>> reports.  sitting across the hudson, i heard of the wtc attack on
>> nanog almost two minutes before it came on television.
> 
> I do hear many stories about twitter letting people get in touch with
> the right organizational contact; a lot of them even "make the news"
> for some definition of "news".  I wonder if they remain newsworthy
> because achieving success is far from guaranteed, whether by
> "traditional" methods or by twitter.

probably because, as with 47.2% of what the press publishes, it sells
papers.

but no, i am not pleased that the most used sources of security and net
failure notifications are twitter and a few mailing lists.  and don't
get me started about the certs as information hoarders.

>> these half-assed "the market demands something" panaceas provide
>> false solutions we have to clean up later; emphasis on that last
>> clause.  rwhois anyone?  the highway is littered with whitepages
>> roadkill.  today there is a massive problem with authority in the IRR
>> (which some RIRs throw in with whois); and retrofitting a solution is
>> now years in blah blah blah.
>> 
>> obligation, before putting the ietf stamp on it, for it to be as good
>> as we can reasonably get for the time.  this proposal is not, as has
>> been enumerated time and again as it has been shoved through the
>> process over objections.
>> 
> I do note the second 'i', but I have to say that to me, "shoved
> through the process over objections" sounds like a pretty serious
> process violation that ought to be remedied.

that may be what you heard, but that is not what i said, or at least
meant to say.

> I'd like to better understand what you see as the process violation
> (if any) here, so that I can try to remedy it.

if i had a process objection, i would say it quite clearly.  i have a
reputation to maintain :)

technical objections have been raised all along the path of this
document.  many of them ignored and repeated, many covered in tero's
most excellent secdir review.  but the draft marched on.  today sm
raised new issues.

but you're a security guy, have the badge and all, even if your name is
not steve.  read the darn thing and tell us what you think of it as
reasonable and prudent secops practice.

randy

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 30 Dec 2019 18:37:07 -0800

> reputation to maintain :)

Okay, thanks for clarifying.

> most excellent secdir review.  but the draft marched on.  today sm

Well, I do remember some objections raised when this draft was still at
SAAG/SECDISPATCH, but I also assigned it a document shepherd and refused to
touch it myself until the shepherd had worked with the authors to address
those comments to the extent that we understood them.  (That was mostly
comments from Paul Wouters, if I remember correctly; there may have been
others.)  So I'm not sure which objections you think have been ignored
while "the draft marched on" -- my intent was to get the initial objections
addressed (and yes, sometimes that was by attempting to make them "out of
scope", which does not always work well), and the next step in the process
is AD review followed by IETF LC.  Having more issues raised during a
single IETF LC isn't surprising (though it is perhaps unusual, with many
drafts getting no LC comments other than directorate reviews, which is
probably a different thread), so "ignored and repeated" and "but the draft
marched on" feel a bit like hyperbole to me.  But maybe I messed up and we
missed something; I'm sure you won't be shy about telling me if that's the
case.

> reasonable and prudent secops practice.

I mean, I read it when I did the AD evaluation, and what I recall thinking
is that it proposes a mechanism that's useful in some cases but potentially
harmful in other cases, so the trick would be to get the writing to be
clear about the risks.  Having it already being in use tends to tilt the
scales towards "document the thing so that the semantics are well-defined",
though that does not absolve us of the duty to accurately document the
drawbacks and risks.  It's a mixed bag, and you'll need to think before
relying on the information in the file, but that's hardly unique to this
mechanism.

-Ben

---

From: Randy Bush <[email-masked]>
Date: Mon, 30 Dec 2019 18:51:28 -0800

> while "the draft marched on"

e.g. mine.  qed.

randy

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 30 Dec 2019 22:23:30 -0500

On Sat, Dec 28, 2019 at 12:13 PM Watson Ladd <[email-masked]> wrote:
>
> Right now the standard is begging on twitter for a chain of introductions. We should be able to do better.
>

As a side point, some organizations publishing a security.txt file,
use Twitter as a preferred contact method. Here is an example:
https://scotthelme.co.uk/.well-known/security.txt

Contact: [email-masked]
Contact: https://twitter.com/Scott_Helme
Encryption: https://scotthelme.co.uk/contact/

Thanks

---

From: Rob Sayre <[email-masked]>
Date: Mon, 30 Dec 2019 19:54:48 -0800

> document at all in this format.

Yeah... I looked at:

https://tools.ietf.org/html/draft-foudil-securitytxt-08#section-6.7

"Organizations SHOULD weigh the advantages of publishing this file versus
the possible disadvantages and increased resources required to triage
security reports."

While the draft does spend some time describing the "Scope of the File", it
doesn't address attacks against other parties using phone numbers or emails
contained within the file.

For example, it seems possible to register free domain names under TLDs
like .xyz and .tk and then point phone numbers at unsuspecting parties.

thanks,
Rob

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 30 Dec 2019 23:00:05 -0500

On Mon, Dec 30, 2019 at 10:55 PM Rob Sayre <[email-masked]> wrote:
>
> On Tue, Dec 24, 2019 at 7:51 AM Tero Kivinen via Datatracker <[email-masked]> wrote:
>>
>> Reviewer: Tero Kivinen
> "Organizations SHOULD weigh the advantages of publishing this file versus the possible disadvantages and increased resources required to triage security reports."
>
> While the draft does spend some time describing the "Scope of the File", it doesn't address attacks against other parties using phone numbers or emails contained within the file.
>
> For example, it seems possible to register free domain names under TLDs like .xyz and .tk and then point phone numbers at unsuspecting parties.
>

I am adding language to address that:
"Attackers can also use this file as a way to spam unrelated third
parties by listing their resources and/or contact information."

And:
"Security researchers SHOULD consult the organization's policy, if
available, and review the contact information and/or resources
referenced within the "security.txt" file before submitting reports in
an automated fashion or as resulting from automated scans."

---

From: Rob Sayre <[email-masked]>
Date: Mon, 30 Dec 2019 20:04:45 -0800

On Mon, Dec 30, 2019 at 8:00 PM Yakov Shafranovich <
[email-masked]> wrote:

> > "Organizations SHOULD weigh the advantages of publishing this file
> versus the possible disadvantages and increased resources required to
> triage security reports."
> >
> > While the draft does spend some time describing the "Scope of the File",
> it doesn't address attacks against other parties using phone numbers or
> emails contained within the file.
> >

OK. Then what level of automation is required?

The semantics of the fields seems hopelessly fuzzy, and so I'm not sure a
well-known URI is required.

thanks,
Rob

---

From: Michael StJohns <[email-masked]>
Date: Mon, 30 Dec 2019 23:06:21 -0500

> triage security reports."

We *really* need to stop treating humans as protocol elements when 
describing how a protocol works or should work.  Placing similar 
guidance in the security consideration section might be a useful thing.  
Using RFC2119 language to constrain or guide the behavior of 
non-computers is probably no better than wishful thinking.

Later, Mike

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 30 Dec 2019 23:16:35 -0500

> required by firewall code versus networking stack of the normal

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

> much more emphasis that this do require human interaction.

I will remove the machine-parseable references

> that file in other locations too, and does not have any effect on the

I will change this to MUST

> I did not find that text at all, so yes, make it more explicit.

Will do

> we do not need to emphasize that.

I will remove the machine-parseable language

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

> I would simply remove the whole text talking about comment and

Will do

> automatically and what we say here does not really matter.

Will address this

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

> that applies. So I would simply just remove section 4.3, as I think

Will do

> is implementing this will not try to implement that SHOULD...

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

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

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

> 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

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 30 Dec 2019 23:24:54 -0500

> non-computers is probably no better than wishful thinking.

As my reply to Tero, we are going to change this

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 31 Dec 2019 14:38:23 +0000

*   While the draft does spend some time describing the "Scope of the File", it doesn't address attacks against other parties using phone numbers or emails contained within the file.

Why is this file worse than any other file on any other web server on the Internet?

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Dec 2019 11:23:54 -0500

> On Dec 31, 2019, at 09:38, Salz, Rich <[email-masked]> wrote:
> 

Because those files are not claiming to be authoritative about a security contact or report method, and can mislead.

If I am a hacker and I gain access, I will want to change this file so the real administrator isn’t notified. How does a security researcher know they aren’t the first to find a vulnerability with write access in the web root? They can’t trust the content, and machine parsing the content seems incredibly dangerous.

Removing or adding some text meant to hint to security researchers that they should not blindly trust this file basically defeats the whole purpose of the file. It just created +1 location for finding possible contact information. And actually more than one due to the whole “discovery” process described in the draft.

The idea is cute and I wish it would work. But it is just adding more dangerous work to the security researcher. Which is fine if that group wants this. But it also adds a new risk to administrators. I now need to check all these possible file locations for maliciously uploaded content that I never wanted to maintain in the first place. That is why I took the rare step of recommending this document is not published. It is unfortunately, potentially harmful to every administrator that is not aware of this document, and might lead to not being properly contacted when there is a security issue. (And if someone claims this is not a concern, than they also say this document isn’t needed at all)

Paul

---

From: Rob Sayre <[email-masked]>
Date: Tue, 31 Dec 2019 15:05:48 -0800

On Tue, Dec 31, 2019 at 6:38 AM Salz, Rich <[email-masked]> wrote:

>
>    - While the draft does spend some time describing the "Scope of the
>    File", it doesn't address attacks against other parties using phone numbers
>    or emails contained within the file.
>
>
>

It's not, but it isn't better either. :)

thanks,
Rob