Subject: [Smart] Draft Charter For SMART Proposed RG

From: Kirsty P <[email-masked]>
Date: Wed, 26 Sep 2018 13:36:52 +0000

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 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. It will research the effects, both positive and negative, of existing, proposed and newly published protocols and Internet standards on attack defence. 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.

The IRTF is in a unique position to provide this research and evidence to the IETF. 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.

## 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.
  *   To highlight the attack mitigation impact, both positive and negative, of new protocols and updates to existing protocols.
  *   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).

## 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.
  *   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.
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 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 [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Thu, 27 Sep 2018 17:59:04 -0400

Kristy and RG ET al.,

I think this charter sounds great and covers most of the areas we need to address in the short-term.  Great work. The deliverables outlined so far will greatly assist the community for years to come.

Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Sep 26, 2018, at 9:36 AM, Kirsty P <Kirsty.p=[email-masked]> wrote:
> 
> To bring evidence on attacks and the methods that are or could be used to defend against them to the attention of the IETF.
> To highlight the attack mitigation impact, both positive and negative, of new protocols and updates to existing protocols.
> 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).
>  
> 
> ## OUTPUTS
> 
> 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.
> 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.
> 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
> 
> -- 
> Smart mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/smart

---

From: Kirsty P <[email-masked]>
Date: Fri, 28 Sep 2018 11:24:03 +0000

Bret,

Thanks for your encouraging words! If you have ideas for more topics that should be covered in the short-term, please feel free to share with the list.

Kirsty

________________________________
From: Bret Jordan <[email-masked]>
Sent: 27 September 2018 22:59:04
To: Kirsty P
Cc: [email-masked]
Subject: Re: [Smart] Draft Charter For SMART Proposed RG

Kristy and RG ET al.,

Bret

On Sep 26, 2018, at 9:36 AM, Kirsty P <Kirsty.p=[email-masked]<mailto:Kirsty.p=[email-masked]>> wrote:

## BACKGROUND

## AIMS

## OUTPUTS

## MEMBERSHIP

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 [email-masked]<mailto:[email-masked]>
--
Smart mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/smart<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fsmart&data=02%7C01%7CKirsty.p%40ncsc.gov.uk%7Ca366352e8c64434aa2dc08d624c4776f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636736823579569953&sdata=OUl%2BBxGgfF2Z5XLQ1iFhGMTdU9ePYXnb0%2F%2BBP9CtpZM%3D&reserved=0>
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 [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Fri, 28 Sep 2018 11:16:57 -0400

Kristy, et al.,

Are we planning on a meet up in Bangkok?  This work along with the work in the CACAO project could really help protect end users and keep them safe. 

Bret 

> On Sep 28, 2018, at 7:24 AM, Kirsty P <[email-masked]> wrote:
> 
> Bret,
>

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Fri, 28 Sep 2018 15:48:50 +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:

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

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

  *

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

  *

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

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

  *

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

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 28 Sep 2018 12:04:32 -0400

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?  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) <[email-masked]>
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.
>
> On Sep 26, 2018, at 9:36 AM, Kirsty P <
> Kirsty.p=[email-masked]> wrote:
>
> 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...
>
>
>
> 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).
>
>
> 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.
>
>    - To bring *evidence on attacks* and the methods that are or could be
>    used to defend against them to the attention of the IETF.
>
>    -
>    - To highlight the *attack mitigation impact*, both positive and
>    negative, *of new protocols* and updates to existing protocols.
>
>    -
>    - *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
>
>    - *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”.
>
>
>    - 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 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 [email-masked]
>
> --
> Smart mailing list
> [email-masked]

-- 

Best regards,
Kathleen

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Fri, 28 Sep 2018 16:26:34 +0000

Hi Kathleen,

Please see inline:

From: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 28, 2018 at 12:04 PM
To: mcgrew <[email-masked]<mailto:[email-masked]>>
Cc: "Kirsty.p=[email-masked]<mailto:Kirsty.p=[email-masked]>" <Kirsty.p=[email-masked]<mailto:Kirsty.p=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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).

Best regards,
Kathleen

On Fri, Sep 28, 2018 at 11:49 AM David McGrew (mcgrew) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kirsty and others,

More inline:

## BACKGROUND

## AIMS

  *

  *

## OUTPUTS

  *

## MEMBERSHIP

Best regards,

David

--

Best regards,
Kathleen

---

From: Kirsty P <[email-masked]>
Date: Fri, 28 Sep 2018 17:45:45 +0000

Bret,

Yes - we are! Kathleen and I are planning a initial meeting in Bangkok at IETF103 to discuss the draft charter and discuss initial problems that the group might research. This meeting won't be one of our three meetings that we are allocated as a Proposed RG - it's just for planning purposes. When we have a date and time for this meeting, I'll post on the list.

I thought it's just worth pointing out here that, though CACAO and SMART have very similar end goals (of protecting users and improving defence against attacks), I really hope that the output from this RG will benefit many other IETF working groups too - such as MILE, DOTS and SACM. In future, these WGs and CACAO might receive output from the research work in a similar way to how the CFRG assists other IETF groups - different work items, but with coordination between our efforts to do much more than we could do alone. We could discuss in Bangkok how best to do such a co-ordination.

Kirsty

________________________________
From: Bret Jordan <[email-masked]>
Sent: 28 September 2018 16:16
To: Kirsty P
Cc: [email-masked]
Subject: Re: [Smart] Draft Charter For SMART Proposed RG

Kristy, et al.,

Bret

On Sep 28, 2018, at 7:24 AM, Kirsty P <[email-masked]<mailto:[email-masked]>> wrote:

Bret,

Kirsty

________________________________
From: Bret Jordan <[email-masked]<mailto:[email-masked]>>
Sent: 27 September 2018 22:59:04
To: Kirsty P
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Smart] Draft Charter For SMART Proposed RG

Kristy and RG ET al.,

Bret

## BACKGROUND

## AIMS

## OUTPUTS

## MEMBERSHIP

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 [email-masked]<mailto:[email-masked]>
--
Smart mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/smart<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fsmart&data=02%7C01%7CKirsty.p%40ncsc.gov.uk%7C8f19ccb106cc4dcd7f8608d625557372%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636737446273966857&sdata=%2B8RA4ZvcMz0nnNKCPR2ez%2BSQ02fc8ocWHMXkOSt0x58%3D&reserved=0>
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 [email-masked]<mailto:[email-masked]>
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 [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Fri, 28 Sep 2018 16:21:52 -0600

I think the use of cyber security and cyber defense are well understood in the market and I am personally okay with their use. 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) <[email-masked]> wrote:
> 
> Hi Kathleen,
> 
> Please see inline:
> 
> From: Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>
> To: mcgrew <[email-masked] <mailto:[email-masked]>>
> Cc: "Kirsty.p=[email-masked] <mailto:Kirsty.p=[email-masked]>" <Kirsty.p=[email-masked] <mailto:Kirsty.p=[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Fri, Sep 28, 2018 at 11:49 AM David McGrew (mcgrew) <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi Kirsty and others,
>>> 
>>>> On Sep 26, 2018, at 9:36 AM, Kirsty P <Kirsty.p=[email-masked] <mailto:Kirsty.p=[email-masked]>> wrote:
>>>> 
>>> 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.  
>>>>> 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 [email-masked] <mailto:[email-masked]>-- 
>>>>> Smart mailing list
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.irtf.org/mailman/listinfo/smart <https://www.irtf.org/mailman/listinfo/smart>
>>> -- 
>>> Smart mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/smart <https://www.irtf.org/mailman/listinfo/smart>
>> 
>> 
>> -- 
>> 
>> Best regards,
>> Kathleen
> -- 
> Smart mailing list
> [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Fri, 28 Sep 2018 16:24:14 -0600

Kristy,

I hope the work products from this research group can impact and influence many working groups, technical committees, and study groups across various SDOs. As we move forward I think we need to ensure the digestibility of the content we produce and ensure that we can have maximum impact across the entire eco-system. 

Thanks,
Bret

> On Sep 28, 2018, at 11:45 AM, Kirsty P <[email-masked]> wrote:
> 
> Bret,
> 
> From: Bret Jordan <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Sep 28, 2018, at 7:24 AM, Kirsty P <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Bret,
>> 
>> From: Bret Jordan <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>>> 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 [email-masked] <mailto:[email-masked]>-- 
>>> Smart mailing list
>>> https://www.irtf.org/mailman/listinfo/smart <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fsmart&data=02%7C01%7CKirsty.p%40ncsc.gov.uk%7C8f19ccb106cc4dcd7f8608d625557372%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636737446273966857&sdata=%2B8RA4ZvcMz0nnNKCPR2ez%2BSQ02fc8ocWHMXkOSt0x58%3D&reserved=0>
>> 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 [email-masked] <mailto:[email-masked]>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 [email-masked] <mailto:[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Sep 2018 23:43:19 +0100

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."
> 
>> From: Kathleen Moriarty <[email-masked]
>> <mailto:[email-masked]>> Date: Friday, September
>> 28, 2018 at 12:04 PM To: mcgrew <[email-masked]
>> <mailto:[email-masked]>> Cc:
>> "Kirsty.p=[email-masked]
>> <mailto:Kirsty.p=[email-masked]>"
>> <Kirsty.p=[email-masked]
>> <mailto:Kirsty.p=[email-masked]>>, "[email-masked]
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> 
>>> 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
>> 
>> 
>>> Best regards, Kathleen
>>> On Fri, Sep 28, 2018 at 11:49 AM David McGrew (mcgrew)
>>> <[email-masked] <mailto:[email-masked]>> 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.
>>>> 
>>>>> On Sep 26, 2018, at 9:36 AM, Kirsty P
>>>>> <Kirsty.p=[email-masked]
>>>>> <mailto:Kirsty.p=[email-masked]>> 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...
>>>>>> 
>>>>>> 
>>>> 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
>>>>>> 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).
>>>>>> 
>>>>>> 
>>>> 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
>>>>>> To highlight the attack mitigation impact, both positive
>>>>>> and negative, of new protocols and updates to existing
>>>>>> protocols.
>>>> 
>>>>>> 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 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
>>>>>> [email-masked] <mailto:[email-masked]>--
>>>>>>  Smart mailing list [email-masked] <mailto:[email-masked]> 
>>>>>> <https://www.irtf.org/mailman/listinfo/smart>
>>>> -- Smart mailing list [email-masked] <mailto:[email-masked]> 
>>>> <https://www.irtf.org/mailman/listinfo/smart>
>>> 
>>> 
>>> --
>>> 
>>> Best regards, Kathleen
>> -- Smart mailing list [email-masked]

---

From: Bret Jordan <[email-masked]>
Date: Fri, 28 Sep 2018 16:59:24 -0600

Stephen,

I respectfully disagree that cyber security is a widely-abused marketing term.  I do agree with you that the “Cloud”, “Hybrid-Cloud” etc are just fancy marketing terms..  If we need to sharpen our pencils to provide some definitions, then lets not argue about it, lets just do it. From my stance, Data Security, Information Security and Cyber Security are very different. 

Thanks,
Bret

> On Sep 28, 2018, at 4:43 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
>>>>> Some detailed comments below.   Please donâ€™t misinterpret
>>>>> I like Stephenâ€™s suggestions of making it an explicit goal to
>>>>> preserve privacy, and citing BCPs.
>>>>> 
>>>>> More inline:
>>>>> 
>>>>>> 
>>>>> I suggest moving the â€œworld of encrypted dataâ€ out of the
>>>>> Itâ€™s important, but not the only consideration, and we
>>>>> donâ€™t want to give people the false impression that the RG is
>>>>> I suggest replacing â€œattack defenseâ€ with
>>>>> â€œcybersecurityâ€ throughout, and defining cybersecurity as
>>>>> doesnâ€™t matter how wise one is about cryptography if the
>>>>> On â€œnegative effectsâ€, what we are most concerned with are
>>>>> I suggest using â€œprotocol designers, implementers, and
>>>>> usersâ€ throughout, instead of focusing on protocol designers.
>>>>> what network and server operators do (or donâ€™t do) can have
>>>>> Itâ€™s a good idea to focus on research and evidence,
>>>>> Instead of â€œattack defence methodsâ€ in the above, I suggest
>>>>> something like â€œimpact on cybersecurityâ€.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> Instead of â€œnew protocolsâ€ I suggest â€œprotocol design,
>>>>> deployment, and operationâ€.
>>>>> I think â€œsystematic guidance to designers of new protocolsâ€
>>>>> I would like to see a goal like â€œTo stimulate and generate
>>>>> impact on third partiesâ€ or something like that.
>>>>>>> 
>>>>>>> Internet drafts,â€¯some of which may be published through
>>>>> RG members.   Also, I think it best to say â€œdesign,
>>>>> deployment, and useâ€.
>>>>> I suggest having a goal like â€œPromoting communication between
>>>>> through discussions online and in regular meetingsâ€.
>>>>> 
>>>>> 
>>>>>>> existingâ€¯attack detection methodsâ€¯and determine
>>>>>>> theâ€¯relative effectiveness of theseâ€¯methods against
> <0x5AB2FAF17B172BEA.asc>

---

From: Bret Jordan <[email-masked]>
Date: Fri, 28 Sep 2018 17:03:07 -0600

David,

I like all of your comments and suggestions, but I have a clarifying question:  You state "A nit: we also want drafts whose intended audience are just the RG members.”  Do you mean:

1) the drafts should only be used by the RG or,
2) the drafts can be targeted at lots of groups and we may have some that are specifically targeted to the RG?

Thanks,
Bret

> On Sep 28, 2018, at 9:48 AM, David McGrew (mcgrew) <[email-masked]> wrote:
> 
> Hi Kirsty and others,
>

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sat, 29 Sep 2018 05:25:40 +0530

May I suggest that this nomenclature discussion be tabled and we go on to examine previous work in this area first so that no wheels are reinvented?  

Or first start with a useful summary of such work and existing approaches?

We already have products in the market from cisco and others that deal with this at a network level examining alternatives to DPI - either look at traffic metadata to fingerprint badness or decrypt and re encrypt data on the fly are two common approaches.

Malware and any other kind of online crime investigation and forensics gets that much harder with bad guys having just as much as or better access to strong encryption and the data anonymization that GDPR provides.

What else?

--srs

> On 29-Sep-2018, at 4:29 AM, Bret Jordan <[email-masked]> wrote:
> 
> I respectfully disagree that cyber security is a widely-abused marketing term.  I do agree with you that the “Cloud”, “Hybrid-Cloud” etc are just fancy marketing terms..  If we need to sharpen our pencils to provide some definitions, then lets not argue about it, lets just do it. From my stance, Data Security, Information Security and Cyber Security are very different

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Sep 2018 01:08:47 +0100

FWIW, I think the message below is a good example of why
the kind of explicit text I argued for is needed in any
putative charter.

S.

On 29/09/18 00:55, Suresh Ramasubramanian wrote:
>> I respectfully disagree that cyber security is a widely-abused marketing term.  I do agree with you that the â€œCloudâ€, â€œHybrid-Cloudâ€ etc are just fancy marketing terms..  If we need to sharpen our pencils to provide some definitions, then lets not argue about it, lets just do it. From my stance, Data Security, Information Security and Cyber Security are very different
>