<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-tjw-dbound2-problem-statement-00" submissionType="IETF" category="info" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true" consensus="true">

<front>
<title abbrev="DBOUND2 Problem">Domain Boundaries 2.0 Problem Statement</title><seriesInfo value="draft-tjw-dbound2-problem-statement-00" stream="IETF" status="informational" name="Internet-Draft"></seriesInfo>
<author role="editor" initials="T." surname="Wicinski" fullname="Tim Wicinski"><organization></organization><address><postal><street></street>
<city>Elkins</city>
<code>26241</code>
<country>USA</country>
<region>WV</region>
</postal><email>tjw.ietf@gmail.com</email>
</address></author><date/>
<area>Application</area>
<workgroup>DBOUND2</workgroup>

<abstract>
<t>Internet clients attempt to make inferences about the administrative
relationship based on domain names. Currently it is not possible to confirm
organizational boundaries in the DNS.  Current mitigation strategies have
there own issues.  This memo attempts to outline these issues.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>Working off of the earlier problem statement <xref target="I-D.sullivan-dbound-problem-statement"></xref>,
which we still consider valid.</t>
</section>

<section anchor="terminology"><name>Terminology</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;,
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref>
when, and only when, they appear in all capitals, as shown here.
DNS terminology is as described in <xref target="RFC8499"></xref>.</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
</references>
<references><name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.sullivan-dbound-problem-statement.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
</references>

<section anchor="previous-use-cases"><name>Previous Use Cases</name>
<t>The use cases which involve use of the public suffix list, summarized from
the initial problem statement:</t>

<ul>
<li><t>HTTP State management cookies</t>
</li>
<li><t>User interface indicators</t>
</li>
<li><t>Setting the document.domain property</t>
</li>
<li><t>Email authentication mechanisms</t>
</li>
<li><t>SSL and TLS certificates</t>
</li>
<li><t>HSTS and Public Key Pinning</t>
</li>
<li><t>Linking domains together</t>
</li>
</ul>
<t>While all of these are very important to solve, part of the issue with
the first attempt to address this was overreaching goals.  The suggestion is
to initially limit the list to a subset, such as these:</t>

<ul>
<li><t>HTTP State management cookies</t>
</li>
<li><t>SSL and TLS certificates</t>
</li>
<li><t>HSTS and Public Key Pinning</t>
</li>
</ul>
</section>

<section anchor="replicating-the-public-suffix-list"><name>Replicating the Public Suffix List</name>
<t>A main topic that immediately arises from this discussion is the replacement
of the Public Suffix List (PSL).  What does need to be quantified and
understood is the 1) workload needed to update the PSL;  2) how much time
is involved with technical escalations; and 3) the quality of the existing
data in the PSL.  Creating an IANA registry to track such changes could
incur a large workload demand upon IANA staff, and this will need to be
understood.</t>
</section>

<section anchor="solution-space-is-a-problem-space"><name>Solution Space is a Problem Space</name>
<t>The problem requires solutions which are both static lists and DNS zone
data that can be enumerated. Both must be addressed in understanding
the problem.</t>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>None at this time.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>None at this time.</t>
</section>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>The author leans heavily on the initial problem statement and thanks Andrew
Sullivan, John Levine, Murray Kucherawy and Paul Vixie for comments and
suggestions.</t>
</section>

<section anchor="appendix"><name>Appendix</name>
</section>

<section anchor="acknowledgements-1" numbered="false"><name>Acknowledgements</name>
</section>

</back>

</rfc>
