<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->
<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="info"
  docName="draft-nurpmeso-dkim-hash-adaptivity-01"
  ipr="trust200902"
  obsoletes=""
  updates="6376"
  submissionType="IETF"
  xml:lang="en"
  version="3">
<!--
     [CHECK]  FIXME
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902,
         noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN
-->
  <front>

   <title>DKIM Hash Algorithm Adaptivity</title>

   <seriesInfo name="Internet-Draft" value="draft-nurpmeso-dkim-hash-adaptivity-01"/>

    <author fullname="Steffen Nurpmeso" initials="S" role="editor" surname="Nurpmeso">
      <address><email>steffen@sdaoden.eu</email></address>
    </author>

    <date year="2024" month="10" day="31"/>

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>DKIM</keyword>

    <abstract><t>
      DKIM (RFC 6376, section 3.7) defines how "data-hash" is generated as input
      to a RSA (RFC 8017) "sig-alg".
      Modern signature algorithms (for example EdDSA, RFC 8032) include extensive
      data hashing as part of the signing process.
      This memo allows DKIM signing algorithm "data-hash" adaptivity,
      taking advantage of algorithm progress and digital signature API reality.
    </t></abstract>

  </front>
  <middle>

    <section>
      <name>Introduction</name>
      <t>
        In section 3.7
        DKIM<xref target="RFC6376"/>
        specifies the algorithm how
        "Computing the Message Hashes"
        for
        IMF<xref target="RFC5322"/>
        messages has to be performed,
        and notes that real life digital signature APIs often combine hashing
        and signing into a single call that performs both,
        "hash-alg" and "sig-alg".
        Different to the
        RSA<xref target="RFC8017"/>
        algorithm solely supported by DKIM at the time of creation,
        modern algorithms like for example
        EdDSA<xref target="RFC8032"/>
        include extensive data hashing as part of digital signature creation.
      </t><blockquote>
        INFORMATIVE NOTE:
        EdDSA was adapted to DKIM as
        Ed25519-SHA256<xref target="RFC8463"/>
        in 2018, but has not gained much traction in the six years since its
        introduction.
        A survey of DKIM implementations revealed necessity for error prone
        extra code paths to implement it with existing APIs.
      </blockquote><t>
        In its current form DKIM defines the generated "data-hash" as the sole
        input of "sig-alg".
        But modern signing algorithms then perform "prehashing",
        applying hashing to the "data-hash".
        With the mentioned Ed25519-SHA256, for example, a 64-byte SHA-256 input
        is prehashed with SHA-512 to a 128-byte output.
        The conclusion is that currently the standard
        complicates implementations,
        fosters data processing redundancy,
        and potentially weakens security attributes of algorithms by feeding in
        only data subsets, prefiltered by potentially weak(er) algorithms.
      </t>
    </section>

    <section>
      <name>Algorithm Adaptivity</name>
      <t>
        The computation described in
        DKIM<xref target="RFC6376"/>
        section 3.7 is modified so that the described input to "sig-alg",
        the "data-hash",
        can adapt to standardized algorithms as appropriate.
        If an algorithm chooses adaption,
        "hash-alg" is only used to produce the "body-hash",
        whereas the input formerly used to create the "data-hash"
        is fed into "sig-alg" instead of to "hash-alg".
        More formally,
        the new pseudo-code for the signature algorithm is:
      </t><sourcecode><![CDATA[
body-hash = hash-alg (canon-body, l-param)
data-hash = hash-alg (h-headers, D-SIG, body-hash)
signature = sig-alg (d-domain, selector,
                     data-hash / (h-headers, D-SIG, body-hash))
      ]]></sourcecode>
    </section>

    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security">
      <name>Security Considerations</name>
      <t>
        This specification should reduce implementation burden and complexity,
        aids hash hardening of affected algorithms to a certain extend,
        and potentially increases, dependent upon algorithm, data volume
        and API optimization efforts, processing performance.
      </t>
    </section>

  </middle>
  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/>
      </references>

      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8463.xml"/>
      </references>
    </references>

 </back>
</rfc>
<!-- vim:set tw=1000:s-ts-mode -->
