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) ___________________________________________________________________
- Re: [Last-Call] Last Call: <draft-foudil-security… Mark Nottingham
- Re: [Last-Call] Last Call: <draft-foudil-security… Yakov Shafranovich
- Re: [Last-Call] Last Call: <draft-foudil-security… Yakov Shafranovich
- [Last-Call] Last Call: <draft-foudil-securitytxt-… Twombley, Keith
- Re: [Last-Call] Last Call: <draft-foudil-security… Yakov Shafranovich
- Re: [Last-Call] Last Call: <draft-foudil-security… Yakov Shafranovich
- Re: [Last-Call] Last Call: <draft-foudil-security… Yakov Shafranovich
- Re: [Last-Call] [saag] Last Call: <draft-foudil-s… Yakov Shafranovich
- Re: [Last-Call] Last Call: <draft-foudil-security… Mark Nottingham
- Re: [Last-Call] Last Call: <draft-foudil-security… David Rogers
- Re: [Last-Call] Last Call: <draft-foudil-security… Michael Richardson
- Re: [Last-Call] Last Call: <draft-foudil-security… Stephane Bortzmeyer
- Re: [Last-Call] Last Call: <draft-foudil-security… Michael Richardson
- Re: [Last-Call] Last Call: <draft-foudil-security… Salz, Rich