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

"David Rogers" <david.rogers@copperhorse.co.uk> Mon, 06 January 2020 13:54 UTC

Return-Path: <david.rogers@copperhorse.co.uk>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7DB12088D for <last-call@ietfa.amsl.com>; Mon, 6 Jan 2020 05:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=copperhorse.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fMTEsTraDRW for <last-call@ietfa.amsl.com>; Mon, 6 Jan 2020 05:53:56 -0800 (PST)
Received: from seven.mnnet.co.uk (seven.mnnet.co.uk [88.150.144.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CEA120821 for <last-call@ietf.org>; Mon, 6 Jan 2020 05:53:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=copperhorse.co.uk; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+Rx8UoqfCuevBkAuM7zgP64G316yxNOvbZsJx5zSBUg=; b=BZTuDK4Fs4GpC2JNgIT5h6dZ+8 9hH6sB/OQrbHOuqpRJkvvz3kJqpHAcX/s0CwsKwZjwuLDrqbijsNEizzk3M9elVDlYgmAs2OWNB2V /97GnngbmsFf+wazfOS+QK4ktjd3Rlros7RdXndqXWs67KXs4T07KpLj4/vXkWISZiRX4uokTR0f0 1IYvYVb3x2ssq0Rfg0aaCtiI2k3a5Sy5XvthR7ZmgzDVMEzFEe3x3cCmDHXtNMeSyd10hfuelegCK mJyj2KMPV7MLaeB2yjqqDOOiK7ZEUpmcKWYMdAAaPkEQjhqVweci6fpRBb5IQB5bfnwMByzU6Fr/F 0AJApiWg==;
Received: from [178.208.165.53] (port=49486 helo=IDRISMKII) by seven.mnnet.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <david.rogers@copperhorse.co.uk>) id 1ioSpJ-001G73-Pl; Mon, 06 Jan 2020 13:53:49 +0000
From: David Rogers <david.rogers@copperhorse.co.uk>
To: last-call@ietf.org
Cc: yakov@nightwatchcybersecurity.com
Date: Mon, 06 Jan 2020 13:53:52 -0000
Message-ID: <008601d5c498$bb501b40$31f051c0$@copperhorse.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01D5C498.BB5153C0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdXEmHPVdqkczJH3TwaM05QHL5iNJw==
Content-Language: en-gb
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - seven.mnnet.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - copperhorse.co.uk
X-Get-Message-Sender-Via: seven.mnnet.co.uk: authenticated_id: david.rogers@copperhorse.co.uk
X-Authenticated-Sender: seven.mnnet.co.uk: david.rogers@copperhorse.co.uk
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/0GoLntPrAJw0xG8g7peyi0YJoCg>
Subject: Re: [Last-Call] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2020 13:54:01 -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:david.rogers@copperhorse.co.uk> david.rogers@copperhorse.co.uk

Copper Horse

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

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

___________________________________________________________________