Re: [Smart] Draft Charter For SMART Proposed RG

"David McGrew (mcgrew)" <> Mon, 01 October 2018 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8658D130EB5 for <>; Mon, 1 Oct 2018 14:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P12YWR5ANwcb for <>; Mon, 1 Oct 2018 14:31:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FA59130EB4 for <>; Mon, 1 Oct 2018 14:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=21290; q=dns/txt; s=iport; t=1538429495; x=1539639095; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JXoK3d/JO6YSTwqlGz7yQogIBvIVKuNIkc8lcc9S004=; b=QdGdArn90oq+Er3JFpQP+NTj7PjdSN4nrz3akLscrAA6WtVHfZLja+Go m6dW6V1Sx7vL2aZEzPn4X9GoHMbb35MHn82nQE4HXE/ZVnhC3FeamYmy9 WKvdEehGekeUR2I5oM9wphrFDFj2kJVaK+jKv+lJsU4Wt3qiNYEG7dRyx E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,328,1534809600"; d="scan'208";a="458035685"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 21:31:02 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w91LV1xc003934 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Oct 2018 21:31:01 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Oct 2018 16:31:01 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Mon, 1 Oct 2018 16:31:00 -0500
From: "David McGrew (mcgrew)" <>
To: Stephen Farrell <>
CC: "" <>, Kathleen Moriarty <>, "" <>, Bret Jordan <>
Thread-Topic: [Smart] Draft Charter For SMART Proposed RG
Thread-Index: AQHUVq1WdAw7d8Bo+EymUcmgu7E5/6UF6OYAgABHcwD//8MYAIAAplUAgAAF/4CABF+6gA==
Date: Mon, 01 Oct 2018 21:31:00 +0000
Message-ID: <>
References: <MMXP123MB0847E55749751AA12D26DBFAD7150@MMXP123MB0847.GBRP123.PROD.OUTLOOK.COM> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Smart] Draft Charter For SMART Proposed RG
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Stopping Malware And Researching Threats <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Oct 2018 21:31:40 -0000

Hi Stephen,

As the person who unintentionally re-opened the “cyber” can of worms, let me chime in :-)   I totally agree that we should avoid marketing terms and ambiguous or overloaded terms, and it would be best to have explicit definitions and citations.  



On 9/28/18, 6:43 PM, "Stephen Farrell" <> wrote:

>On 28/09/18 23:21, Bret Jordan wrote:
>> I think the use of cyber security and cyber defense are well
>> understood in the market 
>I'm not sure "the market" is the target readership in this case,
>if what we're after is as-stated.
>> and I am personally okay with their use.
>I'm against the use of ill-defined and widely-abused marketing
>terms for things like this where rigour is better.
>The IETF and
>IRTF were, I think, wise to not go along with (ab)uses of the
>"cloud" term despite people then claiming that'd be a good plan.
>And I think the same applies here.
>Anyway, I'd suggest avoiding contentious terms, (the set of
>cyberblah terms are I think contentious in this context) and
>trying to be precise even if that consumes more words. (Those
>are cheap enough I think:-)
>> Given the target audience of a lot of these work products, the use of
>> cyber* will be more wildly accepted than some of the other terms that
>> will just be found to be confusing.
>> Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8
>> ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however,
>> the only thing that can not be unscrambled is an egg."
>>> On Sep 28, 2018, at 10:26 AM, David McGrew (mcgrew)
>>> <> wrote:
>>> Hi Kathleen,
>>> Please see inline:
>>> From: Kathleen Moriarty <
>>> <>> Date: Friday, September
>>> 28, 2018 at 12:04 PM To: mcgrew <
>>> <>> Cc:
>>> "
>>> <>"
>>> <
>>> <>>, "
>>> <>" < <>> 
>>> Subject: Re: [Smart] Draft Charter For SMART Proposed RG
>>>> Hi David,
>>>> Thank you very much for the detailed feedback.  I have limited
>>>> time at the moment, but was the one who helped remove the word
>>>> cyber from earlier versions of the charter in an effort to use
>>>> terms that are well understood.  Do you have a suggestion that
>>>> improves from attack defense, but doesn't include cyber?
>>> Not off the top of my head, but I agree with the need to use well
>>> defined terms, because we hope to engage multiple communities.
>>> Perhaps we would be better off defining exactly what we mean.  I
>>> had actually looked through RFC4949 for a reference, with no luck.
>>> Thanks
>>> David
>>>> Sorry for the top post on very helpful feedback (more on that
>>>> later from at least one of us).
>>>> Glad to see you engaged in the conversation!
>>>> Best regards, Kathleen
>>>> On Fri, Sep 28, 2018 at 11:49 AM David McGrew (mcgrew)
>>>> < <>> wrote:
>>>>> 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
>>>>>> <
>>>>>> <>> 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
>>>>> (
>>>>> <>)
>>>>> 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
>>>>>>> <>--
>>>>>>>  Smart mailing list <> 
>>>>>>> <>
>>>>> -- Smart mailing list <> 
>>>>> <>
>>>> --
>>>> Best regards, Kathleen
>>> -- Smart mailing list