Re: [Smart] Draft Charter For SMART Proposed RG

[Stephen Farrell <[e-mail]>]

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
> 
> 
> 
>