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 <david.rogers@xxxxxxxxxxxxxxxxx> wrote:
> 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/Vulnerability-Disclosure-Design-v4.pdf
> Thanks,
> David.
> ___________________________________________________________________
> David Rogers MBE
> Chief Executive Officer
> david.rogers@xxxxxxxxxxxxxxxxx
> Copper Horse
> Web: https://www.copperhorse.co.uk
> Twitter: https://twitter.com/drogersuk (@drogersuk)
> ___________________________________________________________________
> ----------------------------------------------------
> Alternatives:
> ----------------------------------------------------
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
