<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.33 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schwartz-dnsop-dnssec-strict-mode-00" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="DNSSEC Strict Mode">DNSSEC Strict Mode</title>
    <seriesInfo name="Internet-Draft" value="draft-schwartz-dnsop-dnssec-strict-mode-00"/>
    <author initials="B." surname="Schwartz" fullname="Benjamin M. Schwartz">
      <organization>Google LLC</organization>
      <address>
        <email>bemasc@google.com</email>
      </address>
    </author>
    <date year="2021" month="February" day="22"/>
    <area>General</area>
    <workgroup>dnsop</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>Currently, the DNSSEC security of a zone is limited by the strength of its weakest signature algorithm.  DNSSEC Strict Mode makes zones as secure as their strongest algorithm instead.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    mailing list (dnsop@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/dnsop/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/bemasc/dnssec-strict-mode"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="background" numbered="true" toc="default">
      <name>Background</name>
      <section anchor="dnssec-validation-behavior" numbered="true" toc="default">
        <name>DNSSEC validation behavior</name>
        <t>According to <xref target="RFC6840" format="default"/> Section 5.4, when validators (i.e. resolvers) are checking DNSSEC signatures:</t>
        <ul empty="true" spacing="normal">
          <li>a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation.</li>
        </ul>
        <t><xref target="RFC6840" format="default"/> Section 5.11 clarifies further:</t>
        <ul empty="true" spacing="normal">
          <li>Validators SHOULD accept any single valid path.  They SHOULD NOT insist that all algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work.  A validator MAY have a configuration option to perform a signature completeness test to support troubleshooting.</li>
        </ul>
        <t>Thus, validators are required to walk through the set of RRSIGs, checking each one that they are able until they find one that matches or run out.</t>
        <t>Some implementations do offer an option to enforce signature completeness, e.g. Unbound's <tt>harden-algo-downgrade</tt> option <xref target="Unbound" format="default"/>, but most validating resolvers appear to follow the standards guidance on this point.  Validators' tolerance for invalid paths is important due to transient inconsistencies during certain kinds of zone maintenance (e.g. Pre-Publish Key Rollover, <xref target="RFC6781" format="default"/> Section 4.1.1.1).</t>
      </section>
      <section anchor="algorithm-trust-levels" numbered="true" toc="default">
        <name>Algorithm trust levels</name>
        <t>From the viewpoint of any single party, each DNSSEC Algorithm (i.e. signature algorithm) can be assigned some level of perceived strength or confidence.  The party might be a zone owner, considering which algorithms to use, or a validator, consider which algorithms to implement.  Either way, the party can safely include algorithms in which they have maximal confidence (i.e. viewed as secure), and safely exclude algorithms in which they have no confidence (i.e. viewed as worthless).</t>
        <t>Under the current DNSSEC validation behavior, a zone is only as secure as the weakest algorithm implemented by both the signer and the validator.  If there is at least one algorithm that all parties agree offers maximum strength, this is not a problem.  Otherwise, we have a dilemma.  Each party is faced with two options:</t>
        <ul spacing="normal">
          <li>Use/implement only their most preferred algorithms, at the cost of achieving no security with counterparties who distrust those algorithms.</li>
          <li>Use/implement a wide range of algorithms, at the cost of weaker security for counterparties who also implement a wide range of algorithms.</li>
        </ul>
        <t>In practice, zone owners typically select a small number of algorithms, and validators typically support a wide range.  This arrangement often works well, but can fail for a variety of reasons:</t>
        <ul spacing="normal">
          <li>When a new, stronger algorithm is introduced but is not yet widely implemented, zone owners must continue to sign with older, weaker algorithms, typically for many years, until nearly all validators are updated.</li>
          <li>National crypto standards are often highly trusted by some parties, and viewed with suspicion by others.</li>
          <li>Quantum computing has the potential to further confuse the landscape of signature algorithm confidence.  Under the present standards, parties might be required to trust a novel postquantum algorithm of uncertain strength or remain vulnerable to quantum attack.</li>
        </ul>
        <t>This specification resolves these dilemmas by providing zones with the security level of their strongest selected algorithm, instead of the weakest.</t>
      </section>
    </section>
    <section anchor="the-dnssec-strict-mode-flag" numbered="true" toc="default">
      <name>The DNSSEC Strict Mode flag</name>
      <t>The DNSSEC Strict Mode flag appears in bit $N of the DNSKEY flags field.  If this flag is set, all records in the zone MUST be signed correctly under this key's specified Algorithm.  A validator that receives a Strict Mode DNSKEY with a supported Algorithm SHOULD reject as Bogus any RRSet that lacks a valid RRSIG with this Algorithm.  If there are multiple Strict Mode keys for the zone, validators SHOULD validate signatures under each of their Algorithms.</t>
    </section>
    <section anchor="operational-considerations" numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>Once a zone is signed, enabling Strict Mode can be done using any ordinary key rollover procedure (<xref target="RFC6781" format="default"/> Section 4.1), to a new DNSKEY that contains the Strict Mode flag.  When signing a zone for the first time, or adding a new Algorithm, care must be taken to fully sign the zone before enabling Strict Mode.</t>
      <t>By making it safe to use a wider range of DNSSEC Algorithms, this specification could encourage larger RRSIG RRSets, and hence larger responses.</t>
      <t>When a zone has multiple Strict Mode keys, validators will check them all, likely increasing CPU usage.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This specification enables the safe use of signature algorithms with intermediate or indeterminate security.  It does not protect against weak Digest Types in DS records (especially "second preimage" attacks).</t>
      <t>A zone that adds signatures under a less secure algorithm, relying on a strong Strict Mode algorithm for security, will weaken security for validators that have not implemented support for Strict Mode.  Zone owners should use caution when relying on Strict Mode until Strict Mode is widely supported in validators.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is instructed to add this allocation to the DNSKEY RR Flags registry:</t>
      <table align="center">
        <thead>
          <tr>
            <th align="left">Number</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">$N</td>
            <td align="left">STRICT</td>
            <td align="left">(This document)</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC6840">
          <front>
            <title>Clarifications and Implementation Notes for DNS Security (DNSSEC)</title>
            <author fullname="S. Weiler" initials="S." role="editor" surname="Weiler">
              <organization/>
            </author>
            <author fullname="D. Blacka" initials="D." role="editor" surname="Blacka">
              <organization/>
            </author>
            <date month="February" year="2013"/>
            <abstract>
              <t>This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set.  It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.</t>
              <t>This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155).  It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6840"/>
          <seriesInfo name="DOI" value="10.17487/RFC6840"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="Unbound" target="https://nlnetlabs.nl/documentation/unbound/unbound.conf/">
          <front>
            <title>unbound.conf</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC6781">
          <front>
            <title>DNSSEC Operational Practices, Version 2</title>
            <author fullname="O. Kolkman" initials="O." surname="Kolkman">
              <organization/>
            </author>
            <author fullname="W. Mekking" initials="W." surname="Mekking">
              <organization/>
            </author>
            <author fullname="R. Gieben" initials="R." surname="Gieben">
              <organization/>
            </author>
            <date month="December" year="2012"/>
            <abstract>
              <t>This document describes a set of practices for operating the DNS with security extensions (DNSSEC).  The target audience is zone administrators deploying DNSSEC.</t>
              <t>The document discusses operational aspects of using keys and signatures in the DNS.  It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.</t>
              <t>This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6781"/>
          <seriesInfo name="DOI" value="10.17487/RFC6781"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAE8XNGAAA5VYa3PcthX9zl+Byp2x3dldWR6ncXamj7UkJ5rYkqOV2kk7
nQRLYklEJEADoDZrW/+9516AS+rlaZWMlw887uPccw84nU6zoEOt5mLv6HS5
PD4Uy+B0HsR7W6i9TK5WTl0/8rKwuZENphZOrsPU59VGuvBpWhhvW/rXq3zq
eca0wYzpixdZLoMqrdvOhQ9FlunWzUVwnQ8vX7z47sXLTDol5+J7ZZSTdbax
7qp0tmuxBy2aXaktnhVzcWKCckaF6RHtnWU+SFP8ImtrYM9W+cw3sOWXj50N
ys+FsVmr5+LfweYT4a0LTq09rrYNXfwny2QXKuvmmZhmAn/aYNKbmVgmn/hh
dPaNMr/JRhvx/s5r60pp9CcZtDVwwdqyVuLdu0N+qRqp67lY4dfnfy/55Sy3
TZYZ6xrMuVbYXJy/PXx5cPDdHJEx6/GLS7OynSnmvFiQrlRhLqoQWj/f3zc1
IlHLlZ+Zeh9Z6RplAtux38V5/S+2NOv9uEhM+/hFhr/pdCqwUnAyR1gPO+ew
Vr2diFApkVCAvHZOh62wayHFJ8RcaC9q3eigCrHa8lgsoUwZKhqkgxcbJa+U
D8Lr0sjQOSVkDSToUDUzIe7jSzQ0nlf3Qvq4qaIrrK4drW9NSSvu1qG0BSWL
WXSj0UVRqyx7Ig6tuYYbCAiWMoU4UmttNN9n2QWMBa4EAcuLvfeXy4u9SfwV
p2d8fX780+XJ+fERXS9/WLx7t7voRyx/OLt8h/dZuhpmHp69f398ehQn46m4
8+j94mf8kFV7Zx8uTs5OF+/24Ai81D7rkylQFyJY4AevgPzWKQo1glEonzu9
wg3mvDn8IA5eic+fE45ubnD9B9y8Pvj21c1NtqmUiXtZU8NjvkU4t0K2rZKO
1pB1LXLZ6iBrVAgFvrIbIyrl1Ixi+UbmXJNYBLdP+sxdy1oXjDkYWclrbV2W
LfIcQdWmJNujJX9+/eoFzFqqnMd+M3s1YTv6Bazz4pmeqZlwytv6Wjn/nL3P
K5Vf0VI9CHsceVTLX4HDfrxIGZB5rlpEzmzj2uL8fHnyPXvUrdc614jrKBgF
IupQ14hzJWkaxnsVCNlvbNl5odccG17FizXqeeQ0QvOIfwcHIq+l02sNHK87
h3A7tvgfg8P3LfbwFPQRDW9lqFAjF5SoAV6Edg34R3Nh2a4OfAxOHUHBhbtM
3hCjRqc57T3I/6+1Tpc/Hv88Wg+mLYb0CQBaAAAoVUGkosvORVzYln8AhVY5
YjeMGNgAZNjWyAHKHSVOdY2BvmtbsDVahO1WtQIUbUBkZlS1HeA5Ag1hxKmP
nXYwFVM3sr6CvZhYVpGQYC64KOZvMuBJyRwk1ec9VgMRDfYDOwakmZ+BMYph
GJgZC3iQvnAdXOsCbFraBvVJbuwIGAVqsesasJTjCCii91w94v9EqFk560n/
qRe/VtIVykwpLdMC9Vg6Wahf+wU/f05Db24mYtXBPIv49eiEj7ta6gsdJqxt
XdtN4mogQhL9lR2mGBhmIwOJ1oJwkOEBrU8xuUZ7plFwArAYUOqpXBAB5EyC
tYqOWQvNBPAiGtMGkCCkKZNTPRToIzAvVxgPeCEfsAFJ4p6ClgmuM7zRMw7I
B6emHwAE7SvxI3JyTi7ArQki8Dcqvm9fH4yK79XsgP57PmOiWuzaBAsOUatr
VYP/3zrbcBSutdqwu9zXhiJs0eLRABkniXyGtSJXPdDUnoNFiQtBOPQWoPQE
D96VNkAN5ArdvRh1ShcrBpnOVSz4uDlaWVkFXiyGBgggrzmYheIYbioN+0Z1
i8B3Xk1oVTkUyjDpwRk79GL7Y01chUJK3T+aQl55uVagTGSz7go1XgJJjMty
zTANNPJ33ch65FoKGsU7NrHY259HYkqLq9//l8WN/dq6YKdQgTY8QeDSkNPk
SB5VzVda12Ska7g73BUgOzkzEh996KIGWtmQeIey73rOHTKBCJ+s6ZHjbSQh
UmJF2nZYdcfIFH0qGVk6pSKl+BjbrtlBaBKLFv8bi2midRY0RgLrjDbaaALE
RvX8XGi8bCTlmsAdE6ypueVwYqPJg41NLEN99k/i0qv9nacxNlGPMeVAl8Au
YuAhbRMRaRWJ8rG08kqra8IssrfTkrxbDhIjeZN83VQWNvpYrxDofgyH2T1r
JBYBYsA2peKNHreB0+eG3ddce/c2hwYa1cRXNgC+Tgzch2rWOWI8VCngsm11
jhSCUFQNaqK211BKTdesYMRdSwGUUV8bzU7NcGwFswShx/FtTMoarMmdmVR3
XceWQHXLomWdCMFpFSU8jly+T+8/SYpJYdRm0itsN8Y4FSEeFx0BhJZNUNuS
FoBVxApDHdyOQ0NZRLWiI8W+QJUR827rgvgsZWUcjcF9srshWt6igeFN7M0G
N1SfdX1XDHQtblRBMDnl6iYOctuWNt71OxoY41WBYgnMhLVYwczXCQ0pLZFZ
2GTfeVjGpIEoUnUxIn/q0PhQkdTOO+69VWKMFkdRmAwrqPlGIcjkBZbmATW2
8JDeDK0HOsrt5jDQGYrOU953Xk12ZLHrG2NlFMsJSbbUilpUxMdk9LAVLOhM
35bHDcrRSRZqvavpiE4aCSvu5oeA0wGrM+DCtyqH7M0jtSYJwrGAw4l6PEUP
LHWt+ZgQT3uReFiypfLcdc27Z79YUWO+mfSnwDS8Z2o+vFwMh9jxUXNdyzIe
BB95mWQTt6CVDuKPp/3qSQ3TIPCmVnXR8zrxKE2lSCg6aQCiTuV8ykxSmquD
Nfgq9YkCSQZ/5jhyIwExw1gA59Onu4Bi0GJ0dB5rb+4WmE7CAuC+5UeylIMr
ezIZr9WfLZz6jVmqP/hQzUE1q3Q8qJFi30uKdKhKGYOlY8t27Y2qrOnqoMEM
t2yCX54Lu4/GLUmf7ElPRmLZp9hE6d6jYjFm4yfiDAqrr/vDpHlkOvOfkVoY
WnwMPSSeAaIJh2Mbk4wraGxHkpADwuda6bb86cAlHUpIBjFS1T7jQ/h9QQqR
g4Jhhu0zwlElXkRhRaq4Cz/EkomZ7GQDouV94NbaUX/UTVJ7RREH0R6LoS7y
mAbPhBBQFCYyEfcWouIdJFcKS6sHw4HQvtnStxl6jkogtZakZmpMbuiPd9Wy
T/rkNjOg79YFNsOvkyXxoKOuE5HFwEv0W7HIS6+Bgha5VJTs1LXYdqLbR7F2
C14bTZ866BhInhP7oVXW+ipJW2qL5OThh0t4B8MYVcueku5C6gHK4/hFxotx
oiA9zO2J9PjjTqMKTXDns1X/WYLxn/am0sLhyqrYewG6wAVbEoACE5440syP
F9tWMd0cLXfk80yxmdxU97CmRWjRQyDSS7WXOJwV8yJGNErQovD3C1AKUtc7
aTxgzSGIFDxLeYl0fSsZQ6chEPeOTWJOmLHNbXE2VkRkT1L/4Zbs7hUSTRhj
Voh/jXSIrxhwlIxcdpwp/gI1snlsatQZ4yfa91pnYFE9/oLFSDlZnC7uoYQf
sooiVcudi+igKGJhICc2gYca9fhri3jLLcapkgTxFmrtiziNAvKLOOKvgPFj
wBdxTiKcayX+fcHQKf+J/uKBu/gEQ9HceJZYXpyfHF6kNcQzRnj/RfI5hvJX
1hXQQu4u8itjN7UqSnrts8/zKG9V8Ze9NXS02rtBkZwdnUH/9yNRUv8FfC5q
SoIYAAA=

-->

</rfc>
