rfc8953xml2.original.xml		rfc8953.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!--		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	DOCTYPE processing
	To use this XML template, the rfc2629.dtd from the xml2rfc distribution should
	be in the local directory. The xml2rfc distribution is available from
	http://xml.resource.org/
	The ENTITY clauses create an include of the named XML files, which
	contains references written in xml2rfc format.
	XML2RFC offers an include feature described in the XML2RFC README
	file. That syntax, however, contradicts the DTD requirements to
	have <reference> elements within the <references> element, so an
	XML parser is likely to find your XML file invalid. It may be
	possible that XML2RFC will change their DTD so that the XML file
	remains valid when their style of include is used.
	<?rfc toc="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc strict="no"?>
	<?rfc rfcedstyle="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<!-- Document section
	Specify the category attribute per RFC2026
	options are info, std, bcp, or exp.
	docname is the name of the output document. This is optional;
	the default is to use the base portion of the XML filename.
	For Internet-drafts, indicate which intellectual property notice
	to use per the rules of RFC3978. The value (as of this template) can be:
	trust200902 -
	noModificationTrust200902 -
	noDerivativesTrust200902 -
	pre5378Trust200902 -
	The Intellectual Property section will be generated automatically by		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent"
	XML2RFC, based on the ipr attribute in the rfc element.		category="info" docName="draft-moriarty-caris2-04" number="8953"
			ipr="trust200902" sortRefs="true" symRefs="true" tocInclude="true"
			xml:lang="en" version="3">
	If this document obsoletes an RFC, specify the RFC in the "obsoletes" attribute
	If this document updates an RFC, specify the RFC in the "updates" attribute
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent" cat
	egory="info" docName="draft-moriarty-caris2-04" ipr="trust200902" version="3">
	<!-- xml2rfc v2v3 conversion 2.22.3 -->
	<front>		<front>
	<title abbrev="CARIS2 Report">Coordinating Attack Response at Internet		<title abbrev="CARIS2 Report">Coordinating Attack Response at Internet
	Scale 2 (CARIS2) Workshop Report</title>		Scale 2 (CARIS2) Workshop Report</title>
	<seriesInfo name="Internet-Draft" value="draft-moriarty-caris2-04"/>		<seriesInfo name="RFC" value="8953"/>
	<author fullname="Kathleen M Moriarty" initials="K" surname="Moriarty">		<author fullname="Kathleen M. Moriarty" initials="K" surname="Moriarty">
	<organization>Dell Technologies</organization>
			<organization>Center for Internet Security
			</organization>
	<address>		<address>
	<postal>		<postal>
	<street>176 South Street</street>		<street>31 Tech Valley Drive</street>
	<city>Hopkinton</city>		<city>East Greenbush</city>
	<region>MA</region>		<region>NY</region>
	<code>01748</code>		<code>12061</code>
	<country>United States</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>kathleen.moriarty.ietf@gmail.com</email>		<email>kathleen.moriarty.ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2020"/>		<date year="2020" month="December" />
	<!-- IETF area is optional -->
	<area>Security</area>		<area>Security</area>
	<workgroup>Internet Engineering Task Force</workgroup>		<workgroup>Internet Engineering Task Force</workgroup>
	<keyword>Network Management</keyword>		<keyword>Network Management</keyword>
	<keyword>Attack Response</keyword>		<keyword>Attack Response</keyword>
	<keyword>CARIS</keyword>		<keyword>CARIS</keyword>
	<keyword>Incident</keyword>		<keyword>Incident</keyword>
	<!--add additional keywords here for IETF website search engine -->
	<abstract>		<abstract>
	<t>The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop,
	sponsored by the Internet		<t>The Coordinating Attack Response at Internet Scale (CARIS) 2
	Society, took place 28 February and 1 March 2019 in Cambridge,		workshop, sponsored by the Internet Society, took place on 28 February
	Massachusetts, USA. Participants spanned regional, national,		and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned
	international, and enterprise CSIRTs, operators, service providers,		regional, national, international, and enterprise Computer Security
	network and security operators, transport operators and researchers,		Incident Response Teams (CSIRTs), operators, service providers, network
	incident response researchers, vendors, and participants from standards		and security operators, transport operators and researchers, incident
			response researchers, vendors, and participants from standards
	communities. This workshop continued the work started at the first CARIS		communities. This workshop continued the work started at the first CARIS
	workshop, with a focus for CARIS 2 scaling incident prevention and		workshop, with a focus on scaling incident prevention and detection as
	detection as the Internet industry moves to a stronger and a more		the Internet industry moves to a stronger and a more ubiquitous
	ubiquitous deployment of session encryption.</t>		deployment of session encryption.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Introduction</name>		<name>Introduction</name>
	<t>The Coordinating Attack Response at Internet Scale (CARIS) 2		<t>The Coordinating Attack Response at Internet Scale (CARIS) 2
	workshop <xref target="CARISEvent">workshop</xref>, sponsored by the Inter		workshop <xref target="CARISEvent"></xref>, sponsored by the
	net Society, took place 28 February and 1		Internet Society, took place on 28 February and 1
	March 2019 in Cambridge, Massachusetts, USA. Participants spanned		March 2019 in Cambridge, Massachusetts, USA. Participants spanned
	regional, national, international, and enterprise Computer Security Incide		regional, national, international, and enterprise Computer Security
	nt Response Teams (CSIRT), operators,		Incident Response Teams (CSIRTs), operators,
	service providers, network and security operators, transport operators		service providers, network and security operators, transport operators
	and researchers, incident response researchers, vendors, and		and researchers, incident response researchers, vendors, and
	participants from standards communities. This workshop continued the		participants from standards communities. This workshop continued the
	work started at the first CARIS workshop <xref target="RFC8073">RFC8073</x		work started at the first CARIS workshop <xref
	ref>, with a focus for CARIS 2 on scaling		target="RFC8073"></xref>, with a focus on scaling
	incident prevention and detection as the Internet industry moves to		incident prevention and detection as the Internet industry moves to
	a stronger and a more ubiquitous deployment of session encryption.		a stronger and a more ubiquitous deployment of session encryption.
	Considering the related initiative to form a research group <xref target="
	SMART">SMART</xref> in the Internet Research Task Force (IRTF)		Considering the related initiative to form a research group (Stopping
	the focus on prevention included consideration of research opportunities		Malware and Researching Threats <xref target="SMART"></xref>) in the
	to improve protocols and determine if there are ways to improve attack det		Internet Research Task Force (IRTF), the focus on prevention included
	ection		consideration of research opportunities to improve protocols and
	devleoped during the protocol design phase that could later influence prot		determine if there are ways to improve attack detection during
	ocol		the protocol design phase that could later influence protocol
	development in the IETF. This is one way to think about scaling		development in the IETF. This is one way to think about scaling
	response, through prevention and allowing for new methods to evolve for		response, through prevention and allowing for new methods to evolve for
	detection in a post-encrypted world. Although SMART has not progressed,		detection in a post-encrypted world.
	the work to better scale incident response continues through the projects
	proposed at CARIS2 as well in future CARIS workshops.</t>		Although the proposed SMART Research Group has not yet progressed, the work to b
			etter
			scale incident response continues through the projects proposed at CARIS2 as
			well as in future CARIS workshops.</t>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Accepted Papers</name>		<name>Accepted Papers</name>
	<t>Researchers from around the world submitted position and research		<t>Researchers from around the world submitted position and research
	papers summarizing key aspects of their work to help form the shared		papers summarizing key aspects of their work to help form the shared
	content of the workshop. The accepted papers may be found at <xref target=		content of the workshop.
	"CARISEvent">workshop</xref>, and include:</t>
	<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/		The accepted papers may be found at <xref
	> split. -->		target="CARISEvent"></xref> and include:</t>
	<ul empty="true" spacing="normal">		<ul spacing="normal">
	<!-- v2v3: Replaced <t/> with <li/> -->		<li><t>Visualizing Security Automation: <contact fullname="Takeshi
	<li>Visualizing Security Automation: Takeshi Takahashi, NICT,		Takahashi"/>, NICT, Japan</t></li>
	Japan</li>		<li><t>Automating Severity Determination: <contact fullname="Hideaki
	<!-- v2v3: Replaced <t/> with <li/> -->		Kanehara"/>, NICT, Japan</t></li>
	<li>Automating Severity Determination: Hideaki Kanehara, NICT,		<li><t>OASIS's OpenC2: Draper and DoD</t></li>
	Japan</li>		<li><t>Automated IoT Security: <contact fullname="Oscar Garcia-Morchon"/
	<!-- v2v3: Replaced <t/> with <li/> -->		> and
	<li>OASIS's OpenC2, Draper and DoD</li>		<contact fullname="Thorsten Dahm"/></t></li>
	<!-- v2v3: Replaced <t/> with <li/> -->		<li><t>Taxonomies and Gaps: <contact fullname="Kirsty P."/>, UK NCSC</t>
	<li>Automated IoT Security (PASC and PAVA): Oscar Garcia-Morchon and		</li>
	Thorsten Dahm</li>		<li><t>FIRST: <contact fullname="Thomas Schreck"/>, Siemens</t></li>
	<!-- v2v3: Replaced <t/> with <li/> -->		<li><t>NetSecWarriors: <contact fullname="Tim April"/>, Akamai</t></li>
	<li>Taxonomies and Gaps: Kirsty P., UK NCSC</li>		<li><t>Measured Approaches to IPv6 Address Anonymization and Identity
	<!-- v2v3: Replaced <t/> with <li/> -->		Association: <contact fullname="Dave Plonka"/> and <contact
	<li>FIRST: Thomas Schreck, Siemens</li>		fullname="Arthur Berger"/>, Akamai</t></li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>NetSecWarriors: Tim April, Akamai</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Measured Approaches to IPv6 Address Anonymization and Identity
	Association: Dave Plonka and Arthur Berger, Akamai</li>
	</ul>		</ul>
	<t>The program committee worked to fill in the agenda with meaningful		<t>The program committee worked to fill in the agenda with meaningful
	and complementary sessions to round out the theme and encourage		and complementary sessions to round out the theme and encourage
	collaboration to advance research towards the goals of the workshop.		collaboration to advance research toward the goals of the workshop.
	These sessions included:</t>		These sessions included:</t>
	<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/
	> split. -->		<ul spacing="normal">
	<ul empty="true" spacing="normal">		<li><t> Manufacturer Usage Description (MUD) <xref
	<!-- v2v3: Replaced <t/> with <li/> -->		target="RFC8520"></xref>: <contact fullname="Eliot Lear"/>, Cisco</t></l
	<li>		i>
	<xref target="RFC8520">Manufacturer Usage Description		<li><t>TF-CSIRT: <contact fullname="Mirjam Kühne"/>, RIPE NCC</t></li>
	(MUD)</xref>: Eliot Lear, Cisco</li>		<li><t>M2M Sharing Revolution: <contact fullname="Scott Pinkerton"/>,
	<!-- v2v3: Replaced <t/> with <li/> -->		DoE ANL</t></li>
	<li>TF-CSIRT: Mirjam Kuhne, RIPE NCC</li>		<li><t>Comparing OpenC2 with existing efforts, e.g., <xref
	<!-- v2v3: Replaced <t/> with <li/> -->		target="I2NSF">I2NSF</xref>: <contact fullname="Chris Inacio"/></t></li>
	<li>M2M Sharing Revolution, Scott Pinkerton, DoE ANL</li>		<li><t>Alternate Sharing and Mitigation Models: <contact
	<!-- v2v3: Replaced <t/> with <li/> -->		fullname="Kathleen Moriarty"/>, Dell EMC</t></li>
	<li>Comparing OpenC2 with existing efforts, e.g. <xref target="I2NSF">I2
	NSF</xref>: Chris
	Inacio</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Alternate Sharing and Mitigation Models: Kathleen Moriarty,
	DellEMC</li>
	</ul>		</ul>
	<t>The presentations provided interesting background to familiarize		<t>The presentations provided interesting background to familiarize
	workshop attendees with current research work, challenges that require		workshop attendees with current research work, challenges that must be
	addressing for forward progress, and opportunities to collaborate in the		addressed for forward progress, and opportunities to collaborate in the
	desire to better scale attack response and prevention.</t>		desire to better scale attack response and prevention.</t>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>CARIS2 Goals</name>		<name>CARIS2 Goals</name>
	<t>The goal of each CARIS workshop has been to focus on the challenge of		<t>The goal of each CARIS workshop has been to focus on the challenge of
	improving the overall security posture. The approach has been to		improving the overall security posture. The approach has been to
	identify intrinsic or built-in protection capabilities for improved defense,		identify intrinsic or built-in protection capabilities for improved defense,
	automation, and scaling attack response through collaboration and		automation, and scaling attack response through collaboration and
	improved architectural patterns. It has been assumed that it is		improved architectural patterns.
	unlikely that additional training will address the lack of
	information security professionals to fill the job gap.		It has been assumed that additional training will likely not address the lack
	Currently, there is approximately a <xref target="defecit">3 million perso		of information security professionals to fill the job gap. Currently, there
	n deficit</xref> for security		is approximately a <xref target="deficit">three-million-person deficit</xref>
	professionals worldwide and it's only expected to grow. In preparing for t		for security professionals worldwide, and that is only expected to grow. In
	he workshop, the chair and programme committee		preparing for the workshop, the chair and program committee considered that
	considered that this gap cannot be filled through training, but the		this gap cannot be filled through training but requires measures to reduce the
	gap requires measures to reduce the number of information security		number of information security professionals needed through new architectures
	professionals needed through new architectures and research towards		and research toward attack prevention. CARIS2 was specifically focused on the
	attack prevention. CARIS 2 was specifically focused on the industry		industry shift toward the increased use of stronger session encryption (<xref
	shift towards the increased use of stronger session encryption (<xref targ		target="RFC8446">TLSv1.3</xref>, <xref
	et="RFC8446">TLSv1.3</xref>,		target="I-D.ietf-quic-transport">QUIC</xref>, <xref
	<xref target="I-D.ietf-quic-transport">QUIC</xref>, <xref target="RFC8548"		target="RFC8548">tcpcrypt</xref>, etc.) and how prevention and detection can
	>TCPcrypt</xref>, etc.) and how prevention and detection can advance in		advance in this new paradigm. As such, the goals for this workshop
	this new paradigm. As such the goals for this workshop included:</t>		included:</t>
	<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/
	> split. -->
	<ul spacing="normal">		<ul spacing="normal">
	<!-- v2v3: Replaced <t/> with <li/> -->		<li><t>Scale attack response, including ways to improve prevention, as
	<li>Scale attack response, including ways to improve prevention, as
	the Internet shifts to use of stronger and more ubiquitous		the Internet shifts to use of stronger and more ubiquitous
	encryption.</li>		encryption.</t>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>
	<!-- v2v3: Replaced <list style="symbols"/> with <ul/> -->
	<ul spacing="normal">		<ul spacing="normal">
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Determine research opportunities</li>		<li>Determine research opportunities</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Consider methods to improve protocols/provide guidance toward		<li>Consider methods to improve protocols and provide guidance
	goal. For instance, are there ways to build detection of threats		toward goal. For instance, are there ways to build detection of
	into protocols since they cannot be monitored on the wire in the		threats into protocols, since they cannot be monitored on the wire
	future?</li>		in the future?</li>
	</ul>		</ul>
	</li>		</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Identify promising research ideas to seed a research agenda to		<li>Identify promising research ideas to seed a research agenda to
	input to the proposed IRTF SMART research group.</li>		input to the proposed IRTF SMART Research Group.</li>
	</ul>		</ul>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Workshop Collaboration</name>		<name>Workshop Collaboration</name>
	<t>Both CARIS workshops brought together a set of individuals who had		<t>Both CARIS workshops brought together a set of individuals who had
	not previously collaborated toward the goals of scaling attack		not previously collaborated toward the goals of scaling attack
	response. This is		response.
	important as the participants span various areas of Internet technology
	work, research, provide a global perspective, have access to varying
	data sets and infrastructure, and are influential in their area of
	expertise. The specific goals of the CARIS 2 workshop, contributions,
	and the participants were all considered in the design of the breakout
	sessions to both identify and advance research through collaboration.
	The breakout sessions varied in format to keep attendees engaged and
	collaborating, involving the full set of attendees and breakout
	groups.</t>
	<t>The Workshop focused in trying to help identify potential areas
	for collaboration and advance research.  To do this, the workshop
	included 5 different breakout sessions focused on:</t>
	<ol spacing="normal">		This is important as the participants span various areas of Internet
	<li>Standardization and adoption: identify widely adopted and pervasive st		technology work, conduct research, provide a global perspective, have access
	andard protocols and data formats as well as those that failed. </li>		to varying data sets and infrastructure, and are influential in their area of
	<li>Preventative Protocols and Scaling Defense: identify protocols to addr		expertise.
	ess automation at scale.</li>
	<li>Incident Response Coordination: brainstorm on what potential areas of		The specific goals, contributions, and participants of the CARIS2 workshop
	research or future workshops could be held to improve on the scalability of inci		were all considered in the design of the breakout sessions to both identify
	dent response.</li>		and advance research through collaboration.
	<li>Monitoring and Measurement:brainstorm on methods to perform monitoring
	and measurement with the heightened need and requirement to address privacy.</l		The breakout sessions varied in format to keep attendees engaged and
	i>		collaborating; some involved the full set of attendees while others utilized
	<li>Taxonomy and Gaps: brainstorm on away forward for the proposed SMART g		groups.
	roup</li>		</t>
			<t>
			The workshop focused on identifying potential areas for collaboration and
			advancing research.
			</t>
			<ol spacing="normal" type="1">
			<li>Standardization and Adoption: identify widely adopted and pervasive
			standard protocols and data formats as well as those that failed. </li>
			<li>Preventative Protocols and Scaling Defense: identify protocols to
			address automation at scale.</li>
			<li>Incident Response Coordination: brainstorm what potential areas
			of research or future workshops could be held to improve on the
			scalability of incident response.</li>
			<li>Monitoring and Measurement: brainstorm methods to perform
			monitoring and measurement with the heightened need and requirement to
			address privacy.</li>
			<li>Taxonomy and Gaps: brainstorm a way forward for the proposed SMART
			Research Group.</li>
	</ol>		</ol>
	<section>		<section anchor="breakout_1">
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Breakout 1 Results: Standardization and Adoption</name>		<name>Breakout 1 Results: Standardization and Adoption</name>
	<t>This breakout session considered points raised in the preceding talks		<t>This breakout session considered points raised in the preceding
	on hurdles for automating security controls, detection, and response as		talks on hurdles for automating security controls, detection, and
	the teams presenting noted		response; the teams presenting noted several challenges they still
	several challenges they still face today. The breakout		face today. The breakout session worked toward identifying standard prot
	worked toward identifying standard protocols and data formats that		ocols
	succeeded in achieving adoption as well as several that failed or only		and data formats that succeeded in achieving adoption as well as
	achieved limited adoption. The results from the evaluation were		several that failed or only achieved limited adoption. The results
	interesting and could aid in achieving greater adoption when		from the evaluation were interesting and could aid in achieving
	new work areas are developed. The results follow:</t>		greater adoption when new work areas are developed. The following
			subsections detail the results.
			</t>
	<section>		<section>
	<name>Wide adoption:</name>
	<t>Secure Sockets Layer (SSL), now replaced by Transport Layer		<name>Wide Adoption</name>
	Security (TLS) protocol.</t>		<t>
			The Transport Layer Security (TLS) protocol has replaced the Secure Sockets
			Layer (SSL) protocol.</t>
	<t>Observations: There was a clear need for session encryption at the		<t>Observations: There was a clear need for session encryption at the
	transport layer to protect application data. eCommerce was a driving		transport layer to protect application data. E-commerce was a driving
	force at the time with a downside to those who did not adopt. Other		force at the time with a downside to those who did not adopt. Other
	positive attributes that aided adoption were modular design, clean		positive attributes that aided adoption were modular design, clean
	interfaces, and being first to market.</t>		interfaces, and being first to market.</t>
	<t>Simple Network Management Protocol (SNMP) enables configuration		<t>The Simple Network Management Protocol (SNMP) enables configuration
	management of devices with extension points for private configuration		management of devices with extension points for private configuration
	and management settings. SNMP is widely adopted and is only now after		and management settings. SNMP is widely adopted and is only now, after
	decades being replaced by a newer alternative, YANG (a data modeling lan		decades, being replaced by a newer alternative, YANG (a data modeling
	guage) facilitating configuration management via NETCONF or RESTCONF.		language) that facilitates configuration management via the Network
	The SNMP protocol facilitated an		Configuration Protocol (NETCONF) or RESTCONF. SNMP facilitated an
	answer to a needed problem set: configuration, telemetry, and network		answer to a needed problem set: configuration, telemetry, and network
	management. It's development considered the connection between the		management. Its development considered the connection between the
	user, vendor, and developers. Challenges did surface for adoption from		user, vendor, and developers. Challenges did surface for adoption from
	SNMPv1.1 to 1.2, as there was no compelling reason for adoption. SNMPv3		SNMPv1.1 to 1.2, as there was no compelling reason for adoption. SNMPv3
	gained adoption due to its resilience to attacks by providing		gained adoption due to its resilience to attacks by providing
	protection through improved authentication and encryption.</t>		protection through improved authentication and encryption.</t>
	<t>IP Flow Information Export (IPFix) was identified as achieving wide		<t>IP Flow Information Export (IPFIX) was identified as achieving wide
	adoption for several reasons. The low cost of entry, wide vendor		adoption for several reasons. The low cost of entry, wide vendor
	support, diverse user base, and the wide set of use cases spanning		support, diverse user base, and wide set of use cases spanning
	multiple technology areas were some of the key drivers cited.</t>		multiple technology areas were some of the key drivers cited.</t>
	<t>X.509 was explored for its success in gaining adoption. The		<t>X.509 was explored for its success in gaining adoption. The
	solution being abstract from crypto, open, customizable, and		solution being abstract from crypto, open, customizable, and
	extensible were some of the reasons cited for its successful adoption.		extensible were some of the reasons cited for its successful adoption.
	The team deemed it a good solution to a good problem and observed that		The team deemed it a good solution to a good problem and observed that
	government adoption aided its success.</t>		government adoption aided its success.</t>
	</section>		</section>
	<section>		<section>
	<name>Limited Adoption</name>		<name>Limited Adoption</name>
	<t>Next each team evaluated solutions that have not enjoyed wide		<t>Next, each team evaluated solutions that have not enjoyed wide
	adoption.</t>		adoption.</t>
	<t>Although STIX and IODEF are somewhat similar in their goals, the		<t>Although Structured Threat Information eXpression (STIX) and
			the Incident Object Description Exchange Format (IODEF) are somewhat simi
			lar in their goals, the
	standards were selected for evaluation by two separate groups with		standards were selected for evaluation by two separate groups with
	some common findings.</t>		some common findings.</t>
	<t><strong>Structured Threat Information eXpression (STIX)</strong> has		<t>STIX
	had limited adoption by the financial sector, but no		has had limited adoption by the financial sector but no
	single, definitive end user. The standard is still in development with		single, definitive end user. The standard is still in development with
	the US government as the primary developer in partnership with OASIS.		the US government as the primary developer in partnership with OASIS.
	There is interest in using STIX to manage content, but users don't		There is interest in using STIX to manage content, but users don't
	really care about what technology is used for the exchange. The		really care about what technology is used for the exchange. The
	initial goals may not wind up matching the end result for STIX as		initial goals may not wind up matching the end result for STIX, as
	managing content may be the primary use case.</t>		managing content may be the primary use case.</t>
	<t>Incident Object Description Exchange Format (IODEF) was specified		<t>IODEF was specified
	by national research and education networks (NREN) and computer security		by National Research and Education Networks (NRENs) and Computer
	incident response teams (CSIRT) and formalized in the IETF. The user is the		Security Incident Response Teams (CSIRTs) and formalized in the
			IETF <xref target="RFC7970"/>. The user is the
	security operations center (SOC). While there are several		security operations center (SOC). While there are several
	implementations, it is not widely adopted. In terms of exchange, users		implementations, it is not widely adopted. In terms of exchange, users
	are more interested in indicators than full event information and this		are more interested in indicators than full event information, and this
	applies to STIX as well. Sharing and trust are additional hurdles as		applies to STIX as well. Sharing and trust are additional hurdles as
	many are not willing to disclose information.</t>		many are not willing to disclose information.</t>
	<t>DNS-based Authentication of Named Entities (DANE) has DNSsec as a		<t>DNS-Based Authentication of Named Entities (DANE) has DNSSEC as a
	dependency, which is a hurdle towards adoption (too many		dependency, which is a hurdle toward adoption (too many
	dependencies). It has a roll-your-own adoption model, which is risky.		dependencies). It has a roll-your-own adoption model, which is risky.
	While there are some large pockets of adoption, there is still much		While there are some large pockets of adoption, there is still much
	work to do to gain widespread adoption. A regulatory requirement gave		work to do to gain widespread adoption. A regulatory requirement gave
	rise to partial adoption in Germany, which naturally resulted in		rise to partial adoption in Germany, which naturally resulted in
	production of documentation written in German - possibly giving rise		production of documentation written in German -- possibly giving rise
	to further adoption in German-speaking countries. There has also been		to further adoption in German-speaking countries. There has also been
	progress made in the Netherlands through the creation of a website,		progress made in the Netherlands through the creation of a website:
	internet.nl. The website allows you you to test your website for a		<eref target="internet.nl" brackets="angle"/>. The website allows you to
	number of standards (IPv6, DNSSEC, DANE etc.). Internet.nl is a		test your website for a
			number of standards (IPv6, DNSSEC, DANE, etc.). <eref
			target="internet.nl" brackets="angle"/> is a
	collaboration of industry organizations, companies, and the government		collaboration of industry organizations, companies, and the government
	in the Netherlands, and is available for worldwide use.</t>		in the Netherlands and is available for worldwide use.</t>
	<t>IP version 6 (IPv6) has struggled and the expense of running a dual		<t>IP version 6 (IPv6) has struggled, and the expense of running a dual
	stack was one of the highest concerns on the list discussed in the works		stack was one of the highest concerns on the list discussed in the
	hop breakout. The end user for IPv6 is		workshop breakout. The end user for IPv6 is
	everyone and the breakout team considered it too ambiguous. Too many new		everyone, and the breakout team considered it too ambiguous. Too many ne
	requirements have been added		w requirements have been added
	over its 20 year life. The scope of necessary adoption is large with		over its 20-year life. The scope of necessary adoption is large with
	many peripheral devices. Government requirements for support have		many peripheral devices. Government requirements for support have
	helped somewhat with improved interoperability and adoption, but		helped somewhat with improved interoperability and adoption, but
	features like NAT being added to IPv4 slowed adoption. With no new		features like NAT being added to IPv4 slowed adoption. With no new
	features being added to IPv4 and lessons learned, there's still a		features being added to IPv4 and lessons learned, there's still a
	possibility for success.</t>		possibility for success.</t>
	</section>		</section>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->		<name>Breakout 2 Results: Preventative Protocols and Scaling Defense</na
	<name>Breakout 2 Results:Preventative Protocols and Scaling Defense</nam		me>
	e>		<t>This breakout session followed the sessions on MUD, Protocol for
	<t>This next breakout followed the sessions on MUD, PAVA (Protocol for		Automated Vulnerability Assessment (PAVA), and Protocol for Automatic
	Automated Vulnerability Assessment), and PASC (Protocol for Automatic		Security Configuration (PASC), which have themes of automation at scale.
	Security Configuration) which have themes of automation at scale. MUD		MUD
	was designed for IoT and as such, scaling was a major consideration.		was designed for Internet of Things (IoT), and as such, scaling was a ma
			jor consideration.
	The PAVA and PASC work builds off of MUD and maintains some of the		The PAVA and PASC work builds off of MUD and maintains some of the
	same themes. This next breakout was focused on groups brainstorming on		same themes. This breakout session was focused on groups brainstorming
	preventative measures and enabling vendors to deploy mitigations.</t>		preventative measures and enabling vendors to deploy mitigations.</t>
	<t>One group dove a bit deeper into MUD and layer 2 (L2) discovery.		<t>One group dove a bit deeper into MUD and layer 2 (L2) discovery.
	MUD changes sets of filtering control		MUD changes sets of filtering control
	management to the vendor or intermediary MUD vendors for a predictable		management to the vendor or intermediary MUD vendors for a predictable
	platform that scales well. While the overall value of MUD is clear, the		platform that scales well. While the overall value of MUD is clear, the
	use of MUD and what traffic is expected for a particular device should b e considered		use of MUD and what traffic is expected for a particular device should b e considered
	sensitive information as it could be used to exploit a device. MUD has		sensitive information, as it could be used to exploit a device. MUD has
	an option of using L2 discovery to share MUD files. L2 discovery, like		an option of using L2 discovery to share MUD files. L2 discovery, like
	the dynamic host configuration protocol (DHCP) is not encrypted from		the Dynamic Host Configuration Protocol (DHCP), is not encrypted from
	the local client to the DHCP server at this point in time (there is		the local client to the DHCP server at this point in time (there is
	some interest to correct this, but it hasn't received enough support		some interest to correct this, but it hasn't received enough support
	yet). As a result, it is possible to leak information and reveal data		yet). As a result, it is possible to leak information and reveal data
	about the devices for which the MUD files would be applied. This could		about the devices for which the MUD files would be applied. This could
	multicast out information such as network characteristics, firmware		multicast out information such as network characteristics, firmware
	versions, manufacturer, etc. There was some discussion on the use of		versions, manufacturers, etc.
	802.11 to improve connections. Several participants from this group
	planned to research this further and identify options to prevent		There was some discussion on the use of 802.11 to improve connections <xref
	information leakage while achieving the stated goals of MUD.</t>		target="IEEE802.11"/>. Several participants from this group plan to research
			this further and identify options to prevent information leakage while
			achieving the stated goals of MUD.</t>
	<t>The next group discussed a proposal one of the participants had		<t>The next group discussed a proposal one of the participants had
	already begun developing, namely privacy for rendezvous service. The		already begun developing, namely privacy for rendezvous service. The
	basic idea was to encrypt SNI using DNS to obtain public keys. The		basic idea was to encrypt Server Name Indication (SNI) using DNS to obta
	suffix on server IPv6 would be unique to a TLS session (Information		in public keys. The
	missing). The discussion on this proposal was fruitful as the full set		suffix on server IPv6 would be unique to a TLS session (information
			missing). The discussion on this proposal was fruitful, as the full set
	of attendees engaged, with special interest from the incident		of attendees engaged, with special interest from the incident
	responders to be involved in early review cycles. Incident responders		responders to be involved in early review cycles. Incident responders
	are very interested to understand how protocols will change and to		are very interested to understand how protocols will change and to
	assess the overall impact of changes on privacy and security		assess the overall impact of changes on privacy and security
	operations. Even if there are no changes to the protocol proposals		operations. Even if there are no changes to the protocol proposals
	stemming from this review, the group discussion landed on this being a		stemming from this review, the group discussion landed on this being a
	valuable exchange to understand early the impacts of changes for		valuable exchange to understand early the impacts of changes for
	incident detection and mitigation, to devise new strategies and to		incident detection and mitigation, to devise new strategies, and to
	provide assessments on the impact of protocol changes on security in		provide assessments on the impact of protocol changes on security in
	the round.</t>		the round.</t>
	<t>The third group reported back on trust exchanges relying heavily on		<t>
	relationships between individuals. They were concerned with scaling		The third group reported back on trust exchanges relying heavily on
	the trust model and finding ways to do that better. The third breakout		relationships between individuals. They were concerned with scaling the
	dove deeper into this topic.</t>		trust model and finding ways to do that better. The group dove deeper into
			this topic.
	<t>The fourth breakout group discussed useful data for incident		</t>
	responders. This built on the first breakout session. The group
	determined that indicators of compromise (IOCs) are what most		<t>The fourth group discussed useful data for incident
			responders. This built on the first breakout session (<xref target="brea
			kout_1"/>). The group
			determined that indicators of compromise (IoCs) are what most
	organizations and groups are able to successfully exchange. Ideally,		organizations and groups are able to successfully exchange. Ideally,
	these would be fixed and programmable. They discussed developing a		these would be fixed and programmable. They discussed developing a
	richer event threat sharing format. When reporting back to the group,		richer format for sharing event threats. When reporting back to the grou
	a successful solution used in the EU was mentioned, <xref target="MISP">		p,
	Malware Information Sharing Platform (MISP)</xref>. This		a successful solution used in the EU was mentioned: the <xref
	will be considered in their review of existing efforts to determine if		target="MISP">Malware
			Information Sharing Platform (MISP)</xref>. This
			will be considered in the review of existing efforts to determine if
	anything new is needed.</t>		anything new is needed.</t>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Breakout 3 Results: Incident Response Coordination</name>		<name>Breakout 3 Results: Incident Response Coordination</name>
	<t>Incident response coordination currently does not scale. This		<t>Incident response coordination currently does not scale. This
	breakout session focused on brainstorming on incident response and		breakout session focused on brainstorming incident response and
	coordination, looking specifically at what works well for teams today,		coordination, looking specifically at what works well for teams today,
	what is holding them back, and what risks loom ahead. Output from this		what is holding them back, and what risks loom ahead. Output from this
	session could be used to generate research and to dive deeper in a		session could be used to generate research and to dive deeper in a
	dedicated workshop on these topics.</t>		dedicated workshop on these topics.</t>
	<t>Supporting:</t>		<t>Supporting:</t>
	<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing < t/> split. -->
	<ul spacing="normal">		<ul spacing="normal">
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Trust between individuals in incident response teams</li>		<li>Trust between individuals in incident response teams</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Volume of strong signals and automated discovery</li>		<li>Volume of strong signals and automated discovery</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Need to protect network as a forcing function</li>		<li>Need to protect network as a forcing function</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Law and legal catalyst, motivator to stay on top</li>		<li>Law and legal catalyst, motivator to stay on top</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Current efforts supported by profit and company interests, but		<li>Current efforts supported by profit and company interests, but
	those may shift</li>		those may shift</li>
	<!-- v2v3: Replaced <t/> with <li/> -->		<li>Fear initially results in activity or in terms of the diagram
	<li>Fear initially results in activity or in terms of the diagram used		used, a burst of wind, but eventually leads to complacency</li>
	, a burst of wind, but eventually
	leads to complacency</li>
	</ul>		</ul>
	<t>Creating Drag:</t>		<t>What creates drag:</t>
	<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <
	t/> split. -->
	<ul spacing="normal">		<ul spacing="normal">
	<!-- v2v3: Replaced <t/> with <li/> -->		<li>Lack of clear Key Performance Indicators (KPIs)</li>
	<li>Lack of clear KPIs</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Too many standards</li>		<li>Too many standards</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Regional border impact data flows</li>		<li>Potential for regional borders to impact data flows</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Ease of use for end users</li>		<li>Ease of use for end users</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Speed to market without security considerations</li>		<li>Speed to market without security considerations</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Legal framework slow to adapt</li>		<li>Legal framework slow to adapt</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Disconnect in actual/perceived risk</li>		<li>Disconnect in actual/perceived risk</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Regulatory requirements preventing data sharing</li>		<li>Regulatory requirements preventing data sharing</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Lack of clarity in shared information</li>		<li>Lack of clarity in shared information</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Behind the problem/reactionary</li>		<li>Behind the problem/reactionary</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Lack of resources/participation</li>		<li>Lack of resources/participation</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Monoculture narrows focus</li>		<li>Monoculture narrows focus</li>
	</ul>		</ul>
	<t>Looming problems:</t>		<t>Looming problems:</t>
	<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing < t/> split. -->
	<ul spacing="normal">		<ul spacing="normal">
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Dynamic threat landscape</li>		<li>Dynamic threat landscape</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Liability</li>		<li>Liability</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Vocabulary collision</li>		<li>Vocabulary collision</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Lack of target/adversary clarity</li>		<li>Lack of target/adversary clarity</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Bifurcation of Internet</li>		<li>Bifurcation of Internet</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Government regulation</li>		<li>Government regulation</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Confusion around metrics</li>		<li>Confusion around metrics</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Sensitivity of intelligence (trust)</li>		<li>Sensitivity of intelligence (trust)</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Lack of skilled analysts</li>		<li>Lack of skilled analysts</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Lack of "fraud loss" data sharing</li>		<li>Lack of "fraud loss" data sharing</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Stakeholder/leader confusion</li>		<li>Stakeholder/leader confusion</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Unknown impact of emerging technologies</li>		<li>Unknown impact of emerging technologies</li>
	<!-- v2v3: Replaced <t/> with <li/> -->		<li>Overcentralization of the Internet</li>
	<li>Over-centralization of the Internet</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>New technologies and protocols</li>		<li>New technologies and protocols</li>
	<!-- v2v3: Replaced <t/> with <li/> -->		<li>Changes in application-layer configurations (e.g., browser
	<li>Changes in application layer configurations (e.g. browser
	resolvers)</li>		resolvers)</li>
	</ul>		</ul>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Breakout 4 Results: Monitoring and Measurement</name>		<name>Breakout 4 Results: Monitoring and Measurement</name>
	<t>The fourth breakout followed Dave Plonka's talk on IPv6 aggregation		<t>The fourth breakout session followed <contact fullname="Dave Plonka"/ >'s talk on IPv6 aggregation
	to provide privacy for IPv6 sessions. Essentially, IPv6 provides		to provide privacy for IPv6 sessions. Essentially, IPv6 provides
	additional capabilities for monitoring sessions end-to-end. Dave and		additional capabilities for monitoring sessions end to end. Dave and
	his co-author Arthur Berger primarily focus on measurement research,		his coauthor, <contact fullname="Arthur Berger"/>, primarily focus on me
			asurement research
	but found a way to aggregate sessions to assist with maintaining user		but found a way to aggregate sessions to assist with maintaining user
	privacy. If you can devise methods to perform management and		privacy. If you can devise methods to perform management and
	measurement, or even perform security functions, while accommodating		measurement, or even perform security functions, while accommodating
	methods to protect privacy, a stronger result is likely. This also		methods to protect privacy, a stronger result is likely. This also
	precludes the need for additional privacy improvement work to defeat		precludes the need for additional privacy improvement work to defeat
	measurement objectives.</t>		measurement objectives.</t>
	<t>This breakout was focused on devising methods to perform monitoring		<t>This breakout session was focused on devising methods to perform moni toring
	and measurement, coupled with advancing privacy considerations. The		and measurement, coupled with advancing privacy considerations. The
	full group listed out options for protocols to explore and ranked		full group listed out options for protocols to explore and ranked
	them, with the 4 highest then explored by the breakout groups. Groups		them, with the four highest then explored by the breakout groups. Groups
	agreed to work further on the proposed ideas.</t>		agreed to work further on the proposed ideas.</t>
	<section>		<section>
	<name>IP Address Reputation</name>		<name>IP Address Reputation</name>
	<t>There is a need to understand address assignment and configuration		<t>There is a need to understand address assignment and configuration
	for hosts and services, especially with IPv6 <xref target="PlonkaBergerC		for hosts and services, especially with IPv6 <xref
	ARIS2"/> in (1) sharing IP address-related		target="PlonkaBergerCARIS2"/> in (1) sharing IP-address-related
	information to inform attack response efforts, while still protecting		information to inform attack response efforts while still protecting
	the privacy of victims and possible attackers, and (2) mitigating		the privacy of victims and possible attackers and (2) mitigating
	abuse by altering the treatment, e.g., dropping or rate-limiting, of		abuse by altering the treatment, e.g., dropping or rate-limiting, of
	packets. Currently, there is no database for analysts and researchers		packets. Currently, there is no database that analysts and researchers
	can consult to, for instance, determine to lifetimes of IPv6 addresses		can consult to, for instance, determine the lifetimes of IPv6 addresses
	or the prefix length at which the address is expected to be stable		or the prefix length at which the address is expected to be stable
	over time. The researchers propose either introduce a new database (comp		over time. The researchers propose either introducing a new database (co
	are		mpare
	PeerdingDB) or extending existing databases (e.g., the RIRs'), to		PeeringDB) or extending existing databases (e.g., the regional
			Internet registries (RIRs)) to
	contain such information and allowing arbitrary queries. The prefix		contain such information and allowing arbitrary queries. The prefix
	information would either be provided by networks, who are willing, or		information would either be provided by networks that are willing or
	based on measurement algorithms that reverse-engineer reasonable		based on measurement algorithms that reverse-engineer reasonable
	values based on Internet measurements <xref target="PlonkaBergerKIP"/>.		values based on Internet measurements <xref
	In the former case, the incentive of		target="PlonkaBergerKIP"/>.
	networks to provide such information is to so that privacy of their
	users is respected and to limit collateral damage caused by access		In the former case, the incentive of networks to provide such information is
	control lists affecting more of that network's addresses than		to ensure that privacy of their users is respected and to limit collateral
	necessary, e.g., in the face of abuse. This is an early idea, the lead		damage caused by access control lists affecting more of that network's
	to contact if interested to help develop this further is Dave		addresses than necessary, e.g., in the face of abuse.
	Plonka.</t>
			This is an early idea; <contact
			fullname="Dave Plonka"/> is the lead contact
			for those interested in helping to develop this further.</t>
	</section>		</section>
	<section>		<section>
	<name>Server Name Authentication Reputation C (SNARC)</name>		<name>Server Name Authentication Reputation C (SNARC)</name>
	<t>SNARC is a mechanism to assign value to trust indicators, used to		<t>SNARC is a mechanism to
	make decisions about good or bad actors. The mechanism would be able		assign value to trust indicators, used to
	to distinguish between client and server in connections, would be		make decisions about good or bad actors.
	human readable, builds on zero trust networking, and avoids
	consolidation supporting legitimate new players. The group planned to		The mechanism would be able to distinguish between client and server
	research visual aspects and underlying principles as they begin work		connections and would be human readable. In addition, it builds on zero trust
	on this idea. SNARC has a similar theme to the IP reputation/BGP		networking and avoids consolidation, thus supporting legitimate new players.
	ranking idea mentioned above. An RFC would help customers and design
	team on existing solutions. They planned to begin work in several		SNARC has a similar theme to the IP reputation/BGP ranking idea mentioned
	stages, researching "trust" indicators, "trust" value calculations,		above.
	and research actions to apply to "trust". The overarching goal is to
	address blind trust, one of the challenges identified with		SNARC is not currently defined by an RFC; however, such an RFC would help
	information/incident exchanges. If interested to work further with		customers and design teams on existing solutions.
	this team, the lead contact is: Trent Adams.</t>
			The group plans to research visual aspects and underlying principles as they
			begin work on this idea. They plan to begin work in several stages,
			researching "trust" indicators, "trust" value calculations, and research
			actions to apply to "trust".
			The overarching goal is to address blind trust, one of the challenges
			identified with information/incident exchanges. <contact fullname="Trent
			Adams"/> is the lead contact for those interested in working with this
			team.</t>
	</section>		</section>
	<section>		<section>
	<name>Logging</name>		<name>Logging</name>
	<t>The breakout group presented the possibility of injecting logging		<t>The group presented the possibility of injecting logging
	capabilities at compile time for applications, resulting in a more		capabilities at compile time for applications, resulting in a more
	consistent set of logs, covering an agreed set of conditions. If the		consistent set of logs, covering an agreed set of conditions. Using
	log-injecting compiler were used this would increase logging for those		a log-injecting compiler would increase logging for those
	applications and improve the uniformity of logged activity. Increasing		applications and improve the uniformity of logged activity. Increasing
	logging capabilities at the endpoint is necessary as the shift towards		logging capabilities at the endpoint is necessary as the shift toward
	increased use of encrypted transport continues. The lead for contact		increased use of encrypted transport continues. <contact fullname="Nalin
	if interested to develop this further is Nalini Elkins.</t>		i
			Elkins"/> is the lead contact for those interested
			in developing this further.</t>
	</section>		</section>
	<section>		<section>
	<name>Fingerprinting</name>		<name>Fingerprinting</name>
	<t>Fingerprinting has been used for numerous applications on the web,		<t>Fingerprinting has been used for numerous applications on the Web,
	including security, and will become of increasing importance with the		including security, and will become of increasing importance with the
	deployment of stronger encryption. This provides a method to identify		deployment of stronger encryption. Fingerprinting provides a method to
	traffic without using decryption. The group discussed privacy		identify traffic without using decryption. The group discussed privacy
	considerations and balancing how you achieve the security benefits		considerations and balancing how you achieve the security benefits
	(identifying malicious traffic, information leakage, threat		(identifying malicious traffic, information leakage, threat
	indicators, etc.). They are interested to derive methods to validate		indicators, etc.). They are interested in deriving methods to validate
	the authenticity without identifying the source of traffic. They are		the authenticity without identifying the source of traffic. They are
	also concerned with scaling issues. If interested to work further with		also concerned with scaling issues. <contact fullname="William
	this team, the lead contact is: William Weinstein.</t>		Weinstein"/> is the lead contact for those interested in working
			with this team.</t>
	</section>		</section>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Taxonomy and Gaps Session</name>		<name>Taxonomy and Gaps Session</name>
	<t>At the start of day 2, Kirsty Paine and Mirjam Kuhne prepared and		<t>At the start of the second day of the workshop, <contact
	Kirsty led a workshop style session to discuss taxonomies used in		fullname="Kirsty Paine"/> and <contact fullname="Mirjam Kühne"/>
	incident response, attacks, and threat detection, comparing solutions		prepared (and Kirsty led) a workshop-style session to discuss
	and identifying gaps. The primary objective was to determine a path		taxonomies used in incident response, attacks, and threat detection,
	forward selecting language to be used in the proposed SMART group.		comparing solutions and identifying gaps.
	Several taxonomies were presented for review and discussion. The topic
	remains open, the following key points were highlighted by		The primary objective was to determine a path forward by selecting the
	participants:</t>		language to be used in the proposed SMART Research Group.
	<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <
	t/> split. -->		Several taxonomies were presented for review and discussion. The topic
			remains open, but the following key points were highlighted by
			participants:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>A single taxonomy might not be the way to go, because which		<li>A single taxonomy might not be the way to go, because which
	taxonomy you use depends on what problem you are trying to solve;		taxonomy you use depends on what problem you are trying to solve,
	e.g. attribution of the attack, mitigation steps, technical		e.g., attribution of the attack, mitigation steps, technical
	features or organizational impact measurements.</li>		features, or organizational impact measurements.</li>
	<!-- v2v3: Replaced <t/> with <li/> -->		<li>A tool to map between taxonomies should be automated, as there
	<li>A tool to map between taxonomies should be automated as there
	are requirements within groups or nations to use specific		are requirements within groups or nations to use specific
	taxonomies.</li>		taxonomies.</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>The level of detail needed for reporting to management and for		<li>The level of detail needed for reporting to management and for
	the analyst investigating the incident can be very different. At		the analyst investigating the incident can be very different. At
	the workshop, one attendee mentioned that for management reporting		the workshop, one attendee mentioned that, for management reporting,
	they only use 8 categories to lighten the load on analysts,		they only use 8 categories to lighten the load on analysts,
	whereas some of the taxonomies contain 52 categories.</li>		whereas some of the taxonomies contain 52 categories.</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>How you plan to use the taxonomy matters and may vary between		<li>How you plan to use the taxonomy matters and may vary between
	use cases. Take for instance sharing data with external entities		use cases. Take, for instance, sharing data with external entities
	versus internal only. The taxonomy selected depends on what you		versus internal only. The taxonomy selected depends on what you
	plan to do with it. Some stated a need for attribute-based dynamic		plan to do with it. Some stated a need for attribute-based dynamic
	anthologies as opposed to rigid taxonomies used by others. A rigid		anthologies as opposed to rigid taxonomies used by others. A rigid
	taxonomy did not work for many from feedback in the session.</li>		taxonomy did not work for many from feedback in the session.</li>
	<!-- v2v3: Replaced <t/> with <li/> -->		<li><xref target="RFC4949"></xref> was briefly discussed as a possibil
	<li><xref target="RFC4949">RFC4949</xref> was briefly discussed as a p		ity; however, there
	ossibility, however there
	is a clear need to update terminology in this publication around		is a clear need to update terminology in this publication around
	this space in particular. This is likely to be raised in SAAG during		this space in particular. This is likely to be raised in the Securit
	open mic,		y
			Area Advisory Group (SAAG) during the open mic session,
	hopefully with proposed new definitions to demonstrate the issue		hopefully with proposed new definitions to demonstrate the issue
	and evolution of terms over time.</li>		and evolution of terms over time.</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Within a taxonomy, prioritization matters to understand the		<li>
	impact of threats or an attack. How do you map that between		Within a taxonomy, prioritization matters to understand the impact of
	differing taxonomies? (problem to be solved; possible tooling		threats or an attack. How do you map that between differing taxonomies?
	required)</li>		What is the problem to be solved, and what tooling is required?
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Attack attribution had varying degrees of interest. Some felt		</li>
	the public sector cared more about attribution; not about
	individuals, but the possible motivations behind an attack and		<li>Attack attribution had varying degrees of interest.
	likely other victims based on these motivations. Understanding if
	the source was an individual actor, organized crime, or a nation		Some felt the public sector cared more about attribution, not about
	state mattered.</li>		individuals. They were interested in possible motivations behind an attack
			and determining if there were other likely victims based on these motivations.
			Understanding if the source was an individual actor, organized crime, or a
			nation state mattered.
			</li>
	</ul>		</ul>
	<t>The result of this discussion was not to narrow down to one		<t>The result of this discussion was not to narrow down to one
	taxonomy, but to think about mappings between taxonomies and the use		taxonomy but to think about mappings between taxonomies and the use
	cases for exchanging or sharing information, eventually giving rise to		cases for exchanging or sharing information, eventually giving rise to
	a common method to discuss threats and attacks. Researchers need a		a common method to discuss threats and attacks. Researchers need a
	common vocabulary, not necessarily a common taxonomy.</t>		common vocabulary, not necessarily a common taxonomy.</t>
	</section>		</section>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Next Steps</name>		<name>Next Steps</name>
	<t>The next steps from the CARIS2 workshop are twofold. </t>		<t>The next steps from the CARIS2 workshop are twofold:</t>
	<ul spacing="normal">		<ol spacing="normal" type="1">
	<li>The research		<li>The research
	initiatives spawned from the second CARIS require further exploration		initiatives spawned from the second CARIS workshop require further explora tion
	and development. Fostering this development and creating communities		and development. Fostering this development and creating communities
	around each proposed project is the first step, with reports back out to		around each proposed project is the first step, with reports back out to
	the SMART mailing list.</li>		the SMART mailing list.</li>
	<li>The second initiative will be planning for the next CARIS workshop.		<li>The second initiative will be planning for the next CARIS workshop.
	</li>		</li>
	</ul>		</ol>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Summary</name>		<name>Summary</name>
	<t>Wrapping up the workshop, we reviewed the list of agreed projects to		<t>When wrapping up the workshop, we reviewed the list of agreed projects to
	get a feel for actual interest as a follow up. Through the course of the		get a feel for actual interest as a follow up. Through the course of the
	2-day workshop, a larger set of potential research items had		two-day workshop, a larger set of potential research items had
	been generated, and this gave participants a chance to reassess commitment s to		been generated, and this gave participants a chance to reassess commitment s to
	better have them match expected outcomes. The highest ranking projects in		better have them match expected outcomes. The highest ranking projects in
	terms of interest to drive the ideas forward included the following:</t>		terms of interest to drive the ideas forward included the following:</t>
	<!-- v2v3: <ul/> promoted to be child of <section/>, and the enclosing <t/ > split. -->
	<ul spacing="normal">		<ul spacing="normal">
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Traffic fingerprinting</li>		<li>Traffic fingerprinting</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>SNARC</li>		<li>SNARC</li>
	<!-- v2v3: Replaced <t/> with <li/> -->		<li>Attack coordination solutions and automated security</li>
	<li>Attack coordination solutions/automated security</li>		<li>Cryptographic rendezvous</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>Cryptographic Rendezvous</li>
	<!-- v2v3: Replaced <t/> with <li/> -->
	<li>L2 discovery</li>		<li>L2 discovery</li>
	</ul>		</ul>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>There are no security considerations as this is an informational		<t>There are no security considerations, as this is an informational
	workshop summary report.</t>		workshop summary report.</t>
	</section>		</section>
	<section>		<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This memo includes no request to IANA.</t>		<t>This document has no IANA actions.</t>
	</section>
	<section>
	<!-- v2v3: Moved attribute title to <name/> -->
	<name>Acknowledgements</name>
	<t>Thank you to each of the CARIS2 participants who brought their ideas,
	energy and willingness to collaborate to advance attack response at
	Internet scale.</t>
	<t>A big thank you to each member of the program committee for your
	review of program materials, papers, and guidance on the workshop
	format: Mat Ford, Internet Society, UK, Jamie Gillespie, APNIC, AU,
	Chris Inacio, CERT/CC, US, Mirja Kuhlewind, ETH Zurich, CH, Mirjam
	Kuhne, RIPE NCC, NL, Carlos Martinez, LACNIC, UY, Kathleen M. Moriarty,
	Dell EMC (Chair), Kirsty Paine, NCSC, UK, and Takeshi Takahashi, NICT,
	JP.</t>
	<t>Thank you to Megan Hyland, DellEMC, for her review and guidance on
	the breakout session format and tools to enable successful
	collaboration.</t>
	<t>Thank you to the minute takers, Akashaya Khare and Thinh Nguyen,
	DellEMC OCTO Cambridge Dojo team.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<!-- References Section -->
			<displayreference target="I-D.ietf-quic-transport" to="QUIC"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8073.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8073.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.4949.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.4949.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7970.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8446.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8446.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8548.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8548.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8520.xml"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8520.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
	I-D.ietf-quic-transport.xml"/>
	</references>
	<references>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
	<name>URL References</name>		.ietf-quic-transport.xml"/>
	<reference anchor="CARISEvent">
			<reference anchor="CARISEvent" target="https://www.internetsociety.org/e
			vents/caris2">
	<front>		<front>
	<title>CARIS Event Information and Accepted Papers		<title>CARIS2: Coordinating Attack Response at Internet Scale</title
	https://www.internetsociety.org/events/caris2</title>		>
	<author>		<author>
	<organization>Internet Society</organization>		<organization>Internet Society</organization>
	</author>		</author>
	<date year="2019"/>		<date month="February" year="2019"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="I2NSF">		<reference anchor="I2NSF" target="https://datatracker.ietf.org/wg/i2nsf/ about">
	<front>		<front>
	<title>Interface to Network Security Functions (i2nsf)		<title>Interface to Network Security Functions (i2nsf)</title>
	https://datatracker.ietf.org/wg/i2nsf/about</title>
	<author>		<author>
	<organization>IETF</organization>		<organization>IETF</organization>
	</author>		</author>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="defecit">		<reference anchor="deficit" target="https://cybersecurityventures.com/jo bs/">
	<front>		<front>
	<title>Cybersecurity Talent Crunch To Create 3.5 Million Unfilled Jo		<title>Cybersecurity Talent Crunch To Create 3.5 Million Unfilled Jo
	bs Globally By 2021		bs Globally By 2021</title>
	https://cybersecurityventures.com/jobs/</title>
	<author fullname="Steve Morgan">		<author fullname="Steve Morgan">
	<organization>Cybercrime Magazine</organization>		<organization>Cybercrime Magazine</organization>
	</author>		</author>
			<date month="October" year="2019"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="MISP">		<reference anchor="IEEE802.11" target="https://www.ieee802.org/11/">
	<front>		<front>
	<title>Malware Information Sharing Platform		<title>IEEE 802.11 WIRELESS LOCAL AREA NETWORKS</title>
	https://www.misp-project.org/</title>
	<author>		<author>
	<organization>MISP-project.org</organization>		<organization>IEEE</organization>
			</author>
			</front>
			</reference>
			<reference anchor="MISP" target="https://www.misp-project.org/">
			<front>
			<title>Malware Information Sharing Platform</title>
			<author>
			<organization>MISP</organization>
	</author>		</author>
	<date year="2019"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="SMART">		<reference anchor="SMART" target="https://datatracker.ietf.org/group/sma rt/about/">
	<front>		<front>
	<title>Stopping Malware and Researching Threats		<title>Stopping Malware and Researching Threats (smart)</title>
	https://datatracker.ietf.org/group/smart/about/</title>
	<author>		<author>
	<organization>IRTF</organization>		<organization>IRTF</organization>
	</author>		</author>
	<date year="2019"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="PlonkaBergerCARIS2">		<reference anchor="PlonkaBergerCARIS2" target="https://www.internetsocie ty.org/events/caris2">
	<front>		<front>
	<title>CARIS2 Paper Submission,</title>		<title>Measured Approaches to IPv6 Address Anonymization and
	<author>		Identity Association</title>
			<author fullname="David Plonka">
	<organization>CARIS2</organization>		<organization>CARIS2</organization>
	</author>		</author>
	<date year="2019"/>		<author fullname="Arthur Berger">
			<organization>CARIS2</organization>
			</author>
			<date month="March" year="2019"/>
	</front>		</front>
			<refcontent>CARIS2 Paper Submission</refcontent>
	</reference>		</reference>
	<reference anchor="PlonkaBergerKIP">		<reference anchor="PlonkaBergerKIP" target="https://arxiv.org/abs/1707.0 3900">
	<front>		<front>
	<title>kIP: a Measured Approach to IPv6 Address Anonymization		<title>kIP: a Measured Approach to IPv6 Address Anonymization</title
	https://arxiv.org/abs/1707.03900</title>		>
	<author>		<author fullname="David Plonka">
	<organization>Arxiv</organization>		<organization/>
	</author>		</author>
	<date year="2017"/>		<author fullname="Arthur Berger">
			<organization/>
			</author>
			<date month="July" year="2017"/>
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
			<section numbered="false">
			<name>Acknowledgements</name>
			<t>Thank you to each of the CARIS2 workshop participants who brought their
			ideas,
			energy, and willingness to collaborate to advance attack response at
			Internet scale.</t>
			<t>A big thank you to each member of the program committee for your
			review of program materials, papers, and guidance on the workshop
			format: <contact fullname="Mat Ford"/> (Internet Society, UK); <contact
			fullname="Jamie Gillespie"/> (APNIC, AU);
			<contact fullname="Chris Inacio"/> (CERT/CC, US); <contact
			fullname="Mirja Kühlewind"/> (ETH Zurich, CH); <contact fullname="Mirjam
			Kühne"/> (RIPE NCC, NL); <contact fullname="Carlos Martinez"/> (LACNIC,
			UY); <contact fullname="Kathleen M. Moriarty"/>, Chair
			(Dell EMC); <contact fullname="Kirsty Paine"/> (NCSC, UK); and
			<contact fullname="Takeshi Takahashi"/> (NICT, JP).</t>
			<t>Thank you to <contact fullname="Megan Hyland"/> (Dell EMC) for her revi
			ew and guidance on
			the format of breakout sessions and tools to enable successful
			collaboration.</t>
			<t>Thank you to the minute takers, <contact fullname="Akashaya Khare"/>
			and <contact fullname="Thinh Nguyen"/> (Dell EMC OCTO Cambridge Dojo team)
			.</t>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 173 change blocks.
	480 lines changed or deleted		436 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/