Re: [Smart] Draft Charter For SMART Proposed RG

["David McGrew (mcgrew)" <[e-mail]>]

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.  



Thanks

David


On 9/28/18, 6:43 PM, "Stephen Farrell" <[e-mail]> wrote:

>
>Hiya,
>
>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:-)
>
>Cheers,
>S.
>
>> 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)
>>> <[e-mail]> wrote:
>>> 
>>> Hi Kathleen,
>>> 
>>> Please see inline:
>>> 
>>> From: Kathleen Moriarty <[e-mail]
>>> <mailto:[e-mail]>> Date: Friday, September
>>> 28, 2018 at 12:04 PM To: mcgrew <[e-mail]
>>> <mailto:[e-mail]>> Cc:
>>> "Kirsty.p=[e-mail]
>>> <mailto:Kirsty.p=[e-mail]>"
>>> <Kirsty.p=[e-mail]
>>> <mailto:Kirsty.p=[e-mail]>>, "[e-mail]
>>> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> 
>>> 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)
>>>> <[e-mail] <mailto:[e-mail]>> 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
>>>>>> <Kirsty.p=[e-mail]
>>>>>> <mailto:Kirsty.p=[e-mail]>> 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
>>>>> <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
>>>>>>> [e-mail] <mailto:[e-mail]>--
>>>>>>>  Smart mailing list [e-mail] <mailto:[e-mail]> 
>>>>>>> https://www.irtf.org/mailman/listinfo/smart
>>>>>>> <https://www.irtf.org/mailman/listinfo/smart>
>>>>> -- Smart mailing list [e-mail] <mailto:[e-mail]> 
>>>>> https://www.irtf.org/mailman/listinfo/smart
>>>>> <https://www.irtf.org/mailman/listinfo/smart>
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Best regards, Kathleen
>>> -- Smart mailing list [e-mail] 
>>> https://www.irtf.org/mailman/listinfo/smart
>> 
>> 
>> 
>>