IETF Logo Mail Archive

Re: Method of Contact - Consultation on DRAFT Infrastructure and Services Vulnerability Disclosure Statement

Benjamin Kaduk <kaduk@mit.edu> Sun, 09 August 2020 06:15 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55D83A081B; Sat, 8 Aug 2020 23:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 KbretTtsKtqL; Sat, 8 Aug 2020 23:15:32 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 77BD83A0819; Sat, 8 Aug 2020 23:15:32 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0796FPKS003513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 9 Aug 2020 02:15:29 -0400
Date: Sat, 08 Aug 2020 23:15:25 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Paul Wouters <paul@nohats.ca>
Cc: Jay Daley <jay@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Method of Contact - Consultation on DRAFT Infrastructure and Services Vulnerability Disclosure Statement
Message-ID: <20200809061525.GR92412@kduck.mit.edu>
References: <965FAE2A-59D2-4D4B-8D95-76B84483C379@cable.comcast.com> <CAL9jLaa-oJ_Ogp0g8eGH3UOS2BqQ2dLD1Cfwjz6V3e+7kbHtsQ@mail.gmail.com> <0BB5CABB-4CAE-459A-AA0A-8CD761AF63CA@ietf.org> <alpine.LRH.2.23.451.2008061857520.615067@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.23.451.2008061857520.615067@bofh.nohats.ca>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/2FIuPXa2rXgnmcdvFSkLZOutYK8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 06:15:34 -0000

Hi Paul,

On Thu, Aug 06, 2020 at 06:58:56PM -0400, Paul Wouters wrote:
> On Fri, 7 Aug 2020, Jay Daley wrote:
> 
> >> Is the overall effort here really just framing what the security.txt
> >> for all IETF-LLC properties/things should be?
> >
> > Is it your recommendation that we publish a security.txt?  If we were to then I would imagine it would do no more than point to this policy.
> 
> Please don't publish a security.txt file. See the previous discussions
> on SAAG why security.txt is not useful, and actually harmful.

I'm not sure that's an accurate characterization of the previous
discussions.  My notes from the IETF LC indicate that it is perceived to be
harmful when used to attempt to report cases of active compromise, but that
there is an important distinction between a state of active compromise and
a state of vulnerability.  I'm happy to have additional discussion on that
matter, but it's probably most appropriate to have it as a continuation of
https://mailarchive.ietf.org/arch/msg/saag/bmsyx9JKnuugpHvajw9svD0B0ks/ .

Thanks,

Ben

v2.23.0 | Report a Bug | By Email