Subject: Re: [Last-Call] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC

From: "David Rogers" <[email-masked]>
Date: Mon, 6 Jan 2020 13:53:52 -0000

Hi,

I thought I'd provide some feedback as we wrote a report in 2018 assessing
the state of vulnerability disclosure in consumer products[1]. We assessed
331 IoT companies selling the most popular devices in major shops and
websites across the world. The original research found that <10% had any
mechanism for security researchers to contact them. We recently re-ran that
work in order to see what progress had been made in 2019 and I thought I
could add some additional context to this based on our current research
which is about to be published by the IoT Security Foundation. In this
year's review, we looked at additional factors - for example:

.      The usage by companies of a /security page or a redirect to their
actual security page, 4.2% (14)
.      Companies with a security.txt file located at
<domain>/.well-known/security.txt, 0.9% (3)

This illustrates that of the companies we surveyed, there is a very low
awareness (but some) of the concept of security.txt in that location as well
as some limited awareness of the need to redirect /security to help security
researchers. In general we found that the situation is still very poor but
slightly improving and we expect that to significantly improve based on
various governments' efforts to promote vulnerability disclosure policy and
reporting mechanism adoption by, particularly IoT companies.

We wrote a tool to automatically check whether the security.txt exists and
this in itself was useful and expedited our theoretical ability to contact
the companies if we wanted to. For many researchers being able to quickly
wget this file will be very beneficial to them. I have one concern (and I
have seen this already happen) which is that some companies will stop using
a /security web page or other public facing security contact and essentially
'hide' in security.txt. This work should not supplant a /security page but
should be hand-in-hand with it. This would create a technical barrier for
submitting security reports - for example the security report last year by a
young boy against Apple's Facetime would probably have not got through
(rejection is a separate issue!).

I should also add that in many cases where I've wanted to contact companies
in the mobile industry, they have not used a security@ email address. This
could be to avoid spam or it could just simply be that the address was
already being used (I know this is the case in a couple of companies, in the
same way as /security). In some cases however, very obscure email addresses
have been used for no obvious logical reason. I have dealt with a couple of
cases where I've had to facilitate researchers by just getting the email
address in the first place.

In the overall context of a lack of security in IoT companies, I think any
strengthening of the mechanisms by which security researchers can contact
companies is welcomed. I hope that this proposal will be adopted by many,
including governments who are recommending that companies implement CVD for
IoT. The concerns raised about the security.txt file being hijacked are
valid but in my view the same situation exists for any /security page too
currently. 

Therefore, I strongly support the proposal with the amendments already
raised by a number of people on this list and will happily push this into
the mobile and IoT industries once it is published.

[1] Understanding the Contemporary Use of Vulnerability Disclosure in
Consumer IoT Products
https://www.iotsecurityfoundation.org/wp-content/uploads/2018/11/Vulnerabili
ty-Disclosure-Design-v4.pdf 

Thanks,

David.

___________________________________________________________________

David Rogers MBE

Chief Executive Officer

 <mailto:[email-masked]> [email-masked]

Copper Horse

Web:  <https://www.copperhorse.co.uk/> https://www.copperhorse.co.uk 

Twitter:  <https://twitter.com/drogersuk> https://twitter.com/drogersuk
(@drogersuk)

___________________________________________________________________

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jan 2020 11:28:50 -0500

So, in summary, security.txt is useful for contacting companies' about their
products, rather than being useful to report problems about the web site
itself.

Most of the push back from the security review have assumed that the system
is only going to be used by researchers who find problems with the company
web site, and point out how the security.txt could be trojaned.
I find that view very narrow in thinking.

Myself, I find the use a machine parseable file in format ".txt" to be
counter-intuitive.
Others have said it should be .json, and that we should use JOSE to sign.
So my take is that either:

1) it is .txt, free-form intended for humans only, and a OpenPGP clear
   signaturature is appropriate.

2) it is .json, it is machine parseable, and is JOSE signed.

I have never encountered a /security URL myself, so I was unaware of any such
convention.  I see that it works for a few router vendors, approximately 1 in 4.

I think that foundil-securitytxt should go back to saag for discussion.

David Rogers <[email-masked]> wrote:
    > I thought I’d provide some feedback as we wrote a report in 2018 assessing
    > could add some additional context to this based on our current research which
    > is about to be published by the IoT Security Foundation. In this year’s
    > review, we looked at additional factors – for example:

    > · The usage by companies of a /security page or a redirect to their actual
    > security page, 4.2% (14)
    > · Companies with a security.txt file located at

    > various governments’ efforts to promote vulnerability disclosure policy and

    > have seen this already happen) which is that some companies will stop using a
    > /security web page or other public facing security contact and essentially
    > ‘hide’ in security.txt. This work should not supplant a /security page but
    > submitting security reports – for example the security report last year by a
    > young boy against Apple’s Facetime would probably have not got through

    > I should also add that in many cases where I’ve wanted to contact companies
    > cases where I’ve had to facilitate researchers by just getting the email

    > IoT. The concerns raised about the security.txt file being hijacked are valid
    > but in my view the same situation exists for any /security page too
    > currently.

    > Therefore, I strongly support the proposal with the amendments already raised
    > by a number of people on this list and will happily push this into the mobile
    > and IoT industries once it is published.

    > https://www.iotsecurityfoundation..org/wp-content/uploads/2018/11/Vulnerability-Disclosure-Design-v4.pdf

    > [email-masked]

    > Web: https://www.copperhorse.co.uk

    > Twitter: https://twitter.com/drogersuk (@drogersuk)

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------
    > --
    > last-call mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/last-call

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Jan 2020 18:43:43 +0100

On Mon, Jan 06, 2020 at 11:28:50AM -0500,
 Michael Richardson <[email-masked]> wrote 
 a message of 201 lines which said:

> Myself, I find the use a machine parseable file in format ".txt" to
> be counter-intuitive.  Others have said it should be .json, and that
> we should use JOSE to sign.

Strong *no* from me. The entire idea of security.txt was for it to be
simple to *write*, with ordinary tools, and no need to check the
syntax. Otherwise, adoption would probably suffer.

> 2) it is .json, it is machine parseable, and is JOSE signed.

Pointers to software to create JOSE signatures from a JSON file are
welcome.

> I think that foundil-securitytxt should go back to saag for discussion.

I disagree.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jan 2020 12:52:40 -0500

> syntax. Otherwise, adoption would probably suffer.

So, right now, it's machine parseable, so not easy to write.

    > Pointers to software to create JOSE signatures from a JSON file are

There are dozens of such pieces of code.
https://github.com/search?q=JOSE&ref=opensearch
Of the 12,000 results, on the first page of 10 results, 1 is because the
author is named Jose.  The rest are libraries to do exactly what you need.

    > I disagree.

It would be great if you said what you want instead.
Do you want it to go forward as is? (machine parseable .txt)
Or just die?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 6 Jan 2020 18:11:38 +0000

I disagree.

I also agree with Stephane.  This should go forward.