Re: [Smart] Draft Charter For SMART Proposed RG

"David McGrew (mcgrew)" <mcgrew@cisco.com> Fri, 28 September 2018 15:48 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: smart@ietfa.amsl.com
Delivered-To: smart@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C6130E51 for <smart@ietfa.amsl.com>; Fri, 28 Sep 2018 08:48:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Level:
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 xmEcwXyxw-gH for <smart@ietfa.amsl.com>; Fri, 28 Sep 2018 08:48:52 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A7B130E4E for <smart@irtf.org>; Fri, 28 Sep 2018 08:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48036; q=dns/txt; s=iport; t=1538149732; x=1539359332; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=HilHy7s2giceUhLyWMFhiT+W/CtW38ps/WhbtDf91Kk=; b=SIPhy4njxBYKVWILm2ucG/zWpCaf56F0uwrpaizXFT5SQXM2YIhNmxha ChT/jzM8JK+kWfUGmyDLDyIOMhd/zxiwj1CtJe+N661Jz/hO+e6eNuVGm qpOhwKFclelUV6CibIMuastnC0zIrKQHbhbDc2WM2VARcj4NzRCp1hyeO w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BhAAAlTK5b/4gNJK1bGQEBAQEBAQEBAQEBAQcBAQEBAQGCaE0qZn8oCoNqlEeDBZVygWYLGAEKhEkCF4NkITgUAQMBAQIBAQJtHAyFOQIBAwEBFgtLBBcCAQgSJgEGAwICAiULFAMOAgQBEhQHgwYBgR1kD6ROgS6Ed4UUBYg3gQYPCYEMDg8XggCBEicfgU5JBy6DGwEDGIELFRFMAoJJMYImAoYkggSFTI8pCQKGQXyCD4MPg1MXgUeEWoknjAaIdgIRFIElNCGBVXAVOyoBgkGDNwEJh1WFPm8BAQGKbYEugR8BAQ
X-IronPort-AV: E=Sophos;i="5.54,315,1534809600"; d="scan'208,217";a="178192796"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 15:48:51 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w8SFmos3031849 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2018 15:48:51 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 28 Sep 2018 10:48:50 -0500
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1395.000; Fri, 28 Sep 2018 10:48:50 -0500
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Kirsty P <Kirsty.p=40ncsc.gov.uk@dmarc.ietf.org>, "smart@irtf.org" <smart@irtf.org>
Thread-Topic: [Smart] Draft Charter For SMART Proposed RG
Thread-Index: AQHUVq1WdAw7d8Bo+EymUcmgu7E5/6UF6OYA
Date: Fri, 28 Sep 2018 15:48:50 +0000
Message-ID: <064F1F53-248C-4BBD-8C2D-59A4F71874DB@cisco.com>
References: <MMXP123MB0847E55749751AA12D26DBFAD7150@MMXP123MB0847.GBRP123.PROD.OUTLOOK.COM> <B681C76A-CE1F-4C4B-8389-658A01D0E77E@gmail.com>
In-Reply-To: <B681C76A-CE1F-4C4B-8389-658A01D0E77E@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.6.222]
Content-Type: multipart/alternative; boundary="_000_064F1F53248C4BBD8C2D59A4F71874DBciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/smart/G6p1qjeMSG9-nIGUXg3t4m_GFCM>
Subject: Re: [Smart] Draft Charter For SMART Proposed RG
X-BeenThere: smart@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Stopping Malware And Researching Threats <smart.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/smart>, <mailto:smart-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smart/>
List-Post: <mailto:smart@irtf.org>
List-Help: <mailto:smart-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/smart>, <mailto:smart-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Sep 2018 15:48:57 -0000

Hi Kirsty and others,

Thanks for doing this; I very much like the idea of forming an RG that addresses these issues.  An RG where protocol geeks can talk to the threat defense community would be goodness.

Some detailed comments below.   Please don’t misinterpret these comments as being negative on the idea of the RG; the intent is to refine the charter.

I like Stephen’s suggestions of making it an explicit goal to preserve privacy, and citing BCPs.

More inline:


On Sep 26, 2018, at 9:36 AM, Kirsty P <Kirsty.p=40ncsc.gov.uk@dmarc.ietf.org<mailto:Kirsty.p=40ncsc.gov.uk@dmarc.ietf.org>> wrote:


This is the draft charter for the Proposed Research Group: Stopping Malware and Researching Threats (SMART).

Your thoughts and suggestions are very welcome - please post to the list with your comments! - and keep an eye out for a list of proposed research problems soon...



# Stopping Malware and Researching Threats (SMART) Proposed RG - Draft Charter


## BACKGROUND

The first paragraph below probably should precede the Background heading.   I suggest adding a background that outlines cybersecurity issues like the cost of data breaches and the high time-to-detection.
The Stopping Malware and Researching Threats Research Group (or SMART RG) will investigate how cyber attack defence requirements can be met in a world of encrypted data.
I suggest moving the “world of encrypted data” out of the intro sentence, and relegating it to somewhere further down.  It’s important, but not the only consideration, and we don’t want to give people the false impression that the RG is about backdoors in crypto or other ulterior motives.  The following sentence would be a good opener.
It will research the effects, both positive and negative, of existing, proposed and newly published protocols and Internet standards on attack defence.
I suggest replacing “attack defense” with “cybersecurity” throughout, and defining cybersecurity as including the security of the information and the computers and communication systems.   My thinking here is that we should emphasize that SMART is considering the security aspects beyond just the communication security of the protocols.  It might be worth adding something about how endpoint system security is at least as important as protocol/communication security, as it doesn’t matter how wise one is about cryptography if the attacker can exfiltrate their keys.

On “negative effects”, what we are most concerned with are negative externalities in an economic sense, that is, unintended costs or harm that people who design, implement, deploy, and operate protocols on the internet can cause to others.    It would be good to call this out in the charter.  It is already best current practice to avoid negative externalities in the context of DoS attacks (RFC4732, say), and it would be healthy for the internet to have the RG consider externalities around other types of threats.  For instance, the interaction between IP blacklisting and Tor, as presented by Singh et. al. at ANRW 18 (https://dl.acm.org/citation.cfm?id=3232786&dl=ACM&coll=DL) deserves more discussion.
It will gather evidence from information security practitioners on methods used to defend against attacks and make this available to protocol designers. As a result, designers, implementers and users of new protocols will be better informed about the possible impact on attack prevention and mitigation.
 I suggest using “protocol designers, implementers, and users” throughout, instead of focusing on protocol designers.   Also, it might be good to think even more broadly here, because what network and server operators do (or don’t do) can have important effects (e.g. spoofing due to the lack of ingress filtering, and vulnerable servers used to launch attacks).

The IRTF is in a unique position to provide this research and evidence to the IETF.
It’s a good idea to focus on research and evidence, especially around malicious activity observed on the internet or network behaviors seen in malware sandboxes, honeypots, etc.
This research group aims to describe the effect of protocol changes where relevant and stimulate methodical research into attack defence methods for new protocols. Protocols are already rigorously assessed for their security properties, but ensuring attack defence methods are also rigorously assessed alongside protocol design changes would provide a fuller understanding of the value for such change, enabling a better engineered Internet.
Instead of “attack defence methods” in the above, I suggest something like “impact on cybersecurity”.



## AIMS
This research group has these major aims:

  *   To bring evidence on attacks and the methods that are or could be used to defend against them to the attention of the IETF.

More generally, I think we would like to see research on malicious network behavior.

  *
  *   To highlight the attack mitigation impact, both positive and negative, of new protocols and updates to existing protocols.

Instead of “new protocols” I suggest “protocol design, deployment, and operation”.

  *
  *   To stimulate and generate research into attack defence methods for new protocols, and to increase awareness in the technical community of new and existing methodology for detecting and mitigating attacks.
  *   To provide systematic guidance to designers of new protocols as to what attack defence considerations to review, and to inform implementers by default about the effects of new protocols on attack defence.
  *   To produce problem statements that describe key issues in cyber security for the group to research (initial research project ideas are listed below).

I suggest putting the problem statements bullet right after the first bullet, as the RG should be presenting research findings first, then creating problem statements, then proposing solutions.

I think “systematic guidance to designers of new protocols” is an ambitious goal.  It would be nice to have the goal written in a way that it would be easier to make progress against.   It can be difficult for an RG to make timely progress, so from the point of view of the process and the IRTF chairs and the RG chairs, it would be nice to have some more modest or intermediary goals against which headway could be made.

I would like to see a goal like “To stimulate and generate research on network protocols and practices that minimize impact on third parties” or something like that.


## OUTPUTS
The research group plans to create documents that may include, but are not limited to, the following:

  *   Internet drafts, some of which may be published through the IRTF RFC stream. These will include outline problem statements, use cases, case studies and convey research results. They will be written for use by other groups to inform protocol design.

A nit: we also want drafts whose intended audience are just the RG members.   Also, I think it best to say “design, deployment, and use”.

  *
  *   Policy papers, for in-depth analysis and discussion of the relationship between attack defence and the Internet architecture and protocols.
  *   Research papers, containing quantitative evidence of actual attacks and the success of defence methods against them, as well as theoretical and formal analyses of the implications of proposed protocols on attack defence. Defence methods will be analyzed to determine if there are ways to optimize in order to better scale attack detection and mitigation.
  *   Survey of current and historic IETF material to discover existing deliberations on attack defence.
  *   Best practice papers, describing methodologies that will enable researchers to conduct experiments and report results that are useful to designers of protocols. These methodologies will give descriptions of the effects of protocols on attack defence backed by evidence from real-world attacks, laboratory-based testing and theoretical analysis of protocols, through the analysis lens of attacks, detection methods and systematic assessment methodologies.

It is not clear how the papers would relate to the drafts and the RFCs.   It is probably best to say that the RG will invite presentations and discussions of research, policy, and survey papers published elsewhere.   That would help to bring researchers and their results into the RG, while still allowing them to publish in peer-reviewed venues.

I suggest having a goal like “Promoting communication between the IETF community and the cyber threat defense community, through discussions online and in regular meetings”.


Within the first year, the research group aims to:

  *   Survey existing attack detection methods and determine the relative effectiveness of these methods against different attack defence threats (e.g. phishing, DDoS, spambots, C&C, endpoint malware)
  *   Publish case studies of historical attacks and make recommendations where attacks could have been stopped more quickly, or even prevented
  *   Publish an Informational RFC, titled: "Important Attack Defence Considerations for Protocol Design and Deployment".


## MEMBERSHIP
Membership is open to any interested parties who intend to remain current with the published documents and mailing list issues. Wide participation from industry, academia, government and non-profits is encouraged.
This is really good, thanks again for taking the initiative with this.

Best regards,

David






This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk<mailto:ncscinfoleg@ncsc.gov.uk>
--
Smart mailing list
Smart@irtf.org<mailto:Smart@irtf.org>
https://www.irtf.org/mailman/listinfo/smart