<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<!-- One method to get references from the online citation libraries.
 There has to be one entity for each item to be referenced.
 An alternate method (rfc include) is described in the references. -->

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
 please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
 (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
 (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-dcrup-dkim-ecc-00" ipr="trust200902" updates="6376">
    <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->
    
    <!-- ***** FRONT MATTER ***** -->
    
    <front>
        <title abbrev="dkim-ecc">Defining Elliptic Curve Cryptography Algorithms for use with DKIM</title>
        
        <author fullname="Scott Rose" initials="S." surname="Rose">
            <organization>NIST</organization>
            <address>
                <postal>
                    <street>
                        100 Bureau Dr.
                    </street>
                    <city>Gaithersburg</city>
                    <region>MD</region>
                    <code>20899</code>
                    <country>USA</country>
                </postal>
                <phone>+1 301-975-8439</phone>
                <email>scott.rose@nist.gov</email>
                
            </address>
        </author>
        
        <date day="2" month="June" year="2017" />
        
        <!-- Meta-data Declarations -->
        
        <area>Applications</area>
        <workgroup>DCRUP</workgroup>
        <keyword>Internet-Draft</keyword>
        <keyword>Authentication</keyword>
        <keyword>Email</keyword>
        
        <abstract>
        <t>
        DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given
        sending domain.  Currently, there is only one cryptography algorithm defined for use with DKIM
        (RSA). This document defines four new elliptic curve cryptography algorithms for use with
        DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for
        smaller key length to provide the same digital signature strength.
        </t>
        </abstract>
    </front>
    
<middle>
    <section title="Introduction">
        <t>
        DomainKeys Identified Mail (DKIM)<xref target="RFC6376" /> uses digital signatures to associate
        a sending domain with a given message. Each DKIM signed email message as a digital signature in
        its header, that can be validated by a receiver by obtaining the appropriate public key stored
        in the DNS. Currently, DKIM has only one cryptographic algorithm defined for
        use (RSA) and two digital signature algorithms (RSA/SHA-1 and RSA/SHA-256). In the past, 1024-bit
        RSA keys were common, equating to (roughly) a security key strength of 80 bits <xref target="NIST.800-57.2016" />.
        Today, a minimum of 112 bits is recommended, which equates to 2048 bit RSA keys.
        </t>
        <t>
        The public portion of 2048 bit RSA keys are still small enough to fit into a DNS TXT RR without
        issues in performance.  The encoded public key is too large to fit into the maximum allowed characters
        in a single string, but a DNS TXT RR allows for multiple strings, so the key can be broken into "chunks" to
        allow it to be served. However, some code components may not correctly handle TXT RRs with multiple strings which
        will result in errors in validation.
        </t>
        <t>
        Elliptic Curve Cryptography (ECC) has shown to have the same (roughly)
        equivalent key strength with
        smaller sizes.  A 224 to 255 bit ECDSA key has (roughly) the same key strength as a 2048 bit RSA
        key (112 bits of strength). This means smaller keys can be used to achieve the same DKIM security
        strength, as well as being easier to manage in the DNS.
        </t>
        <t>
        Having additional digital signature algorithms defined for use with DKIM also permits algorithm
        agility. If a weakness is discovered in one digital signature algorithm, email senders can quickly
        migrate to another algorithm without waiting for a standards action and subsequent software update.
        </t>
        <t>
        This document defines a ECDSA as a new algorithms for DKIM. This document also defines a new hash algorithm for
        use with DKIM signatures.
        This document updates the IANA registry with new values for the algorithms.
        This document does not change the DKIM key or signature formats, but only defines new algorithm values
        using those formats.
        </t>
        <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
        </t>
      </section>
    </section>
    <section title="Defining New ECC algorithms for Use with DKIM">
        <figure><preamble>
            This document defines a new digital signature algorithm for use with DKIM:
        </preamble>
        <artwork>
          algorithm  |  mnemonic
        -------------+-------------
         ECDSA P-256 |  ecdsa256
         
        </artwork>
        <postamble>
        </postamble>
        </figure>
    
        <t>
        The SHA-512 hash algorithm is also now defined for use with DKIM using the mnemonic 'sha512' for the
        "h=" DKIM key tag and "a=" sig-a-tag-h DKIM signature tag (see below).
        </t>
        <t>
        For ECDSA, the SHA-1 hash algorithm MUST NOT be used. Both ECDSA and RSA MAY be used with SHA-512.
        </t>
       
    </section>
    <section title="Changes to ABNF Definitions of DKIM Keys and Signatures">
        <t>
            The original definition of DKIM signatues and keys are defined in <xref target="RFC6376" />. The following
            are changes to the definition to include the new digital signature algorithm and secure hash algorithm.
        </t>
        <section title="Changes to DKIM Key Definition">
            <t>
                The original definition of the textual representation of DKIM keys is found in section 3.6.1 of <xref target="RFC6376" />.
                The only changes to the definition is below.  The entire key:tag definition is included for clarity.
                All other tags:value pairs are unchanged. References to the definitions below have also been updated to
                reflect the current state of the art.
            </t>
            <t>
            <list style='hanging'>
                <t hangText="h= ">
                    Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
                    "sha256").  A colon-separated list of hash
                    algorithms that might be used.  Unrecognized algorithms MUST be
                    ignored.  Refer to <xref target="RFC6376" />Section 3.3 for a discussion of the hash
                    algorithms implemented by Signers and Verifiers.  The set of
                    algorithms listed in this tag in each record is an operational
                    choice made by the Signer.
                    <vspace blankLines='1' />
                    ABNF:
                    <vspace blankLines='1' />
                    key-h-tag       = %x68 [FWS] "=" [FWS] key-h-tag-alg
                    *( [FWS] ":" [FWS] key-h-tag-alg )
                    key-h-tag-alg   = "sha1" / "sha256" / "sha512" / x-key-h-tag-alg
                    x-key-h-tag-alg = hyphenated-word   ; for future extension
                </t>
                <t hangText="k= ">
                    Key type (plain-text; MANDATORY).  Signers and
                    Verifiers MUST support the "rsa" key type.  The "rsa" key type
                    indicates that an ASN.1 DER-encoded <xref target="UTI.X680.2002" /> RSAPublicKey
                    (see <xref target="RFC8017" />, Sections 3.1 and A.1.1) is being used in the "p="
                    tag.  The "ecdsa256" key type indicates an ASN.1 DER-encoded <xref target="UTI.X680.2002" /> PublicKey
                    (see <xref target="RFC5480" />, Section 2.2) is being used in the "p=" tag.
                    (Note: the "p=" tag further encodes the value using the base64 algorithm.)  Unrecognized key types MUST be ignored.
                    <vspace blankLines='1' />
                    ABNF:
                    <vspace blankLines='1' />
                    key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
                    key-k-tag-type   = "rsa" / "ecdsa256" / x-key-k-tag-type
                    x-key-k-tag-type = hyphenated-word   ; for future extension
                </t>
            </list>
            </t>
        </section>
            <section title="Changes to DKIM Signature Definition">
                <t>
                    The original definition of the textual representation of DKIM signatures is found in section 3.5 of <xref target="RFC6376" />.
                    The only changes to the definition is below.  The entire key:tag definition is included for clarity.
                    All other tags:value pairs are unchanged. References to the definitions below have also been updated to
                    reflect the current state of the art.
                </t>
                <t>
                <list style='hanging'>
                    <t hangText="a=">The algorithm used to generate the signature (plain-text;
                REQUIRED).  Verifiers MUST support "rsa-sha1" and "rsa-sha256" and SHOULD support "ecdsa256-sha256";
                 Signers MUST NOT use "sha1" with "ecdsa256".
                See <xref target="RFC6376" /> Section 3.3 for a
                description of RSA and <xref target="FIPS.186-4.2013" /> Section 6 for a brief description of ECDSA.
                <vspace blankLines='1' />
                ABNF:
                <vspace blankLines='1' />
                sig-a-tag       = %x61 [FWS] "=" [FWS] sig-a-tag-alg
                sig-a-tag-alg   = sig-a-tag-k "-" sig-a-tag-h
                sig-a-tag-k     = "rsa" / "ecdsa256" / x-sig-a-tag-k
                sig-a-tag-h     = "sha1" / "sha256" / "sha512" / x-sig-a-tag-h
                x-sig-a-tag-k   = ALPHA *(ALPHA / DIGIT)
                ; for later extension
                x-sig-a-tag-h   = ALPHA *(ALPHA / DIGIT)
                ; for later extension
                </t>
                </list>
                </t>
            </section>
            
        </section>
    
    <section title="Sender Considerations">
	<t>
	New algorithms for an established protocols take some time to gain wide deployment. There
	will be a period of time where new algorithms are in operation side by side with older 
	algorithms. There will also be a sizable percentage of DKIM validators that will not 
	understand new algorithms until they are upgraded. This will lead to a period of time
	where multiple DKIM signature algorithms are in use for a sender. Email administrators MAY
	want to also sign with RSA/SHA-1 or RSA/SHA-256 for a period of time. This period of time
	is difficult to measure, but DMARC <xref target="RFC7960" /> aggregate reports could provide a
	view on DKIM validation rates by receivers.
	</t>
    </section>
    <section title="Receiver Considerations">
        <t>
    These requirements are for DKIM verifiers (as defined it <xref target="RFC6376" />). These entities would be the consumers of any end-to-end
    email security policy and would be the entity responsible for validating DKIM signatures.
        </t>
        <t>
        DKIM verifiers claiming conformance to this document MUST implement all of the above cryptographic algorithms and
        SHOULD implement the SHA-512 hash algorithm.
        </t>
        <t>
        This document does NOT change the behavior of the core DKIM specification in that verifiers MUST
        ignore unknown algorithms in DKIM signatures.
        </t>
    </section>

    <section title="Security Considerations">
        <t>
        This document defines the use of new elliptic curve cryptographic algorithms for use with DomainKey
        Identified Mail (DKIM). This document is not a discussion of the relative strengths or weaknesses of these
        algorithms, but only defines their use.
        </t>
        <t>
        There is a risk for mail receivers that do not understand or implement the new algorithms.  Attackers could
        modify or spoof messages from sending zones using one of the newly defined algorithms and it would not be
        detectable as an attack by ECC-ignorant receivers. Likewise, ECC-ignorant receivers may mark valid DKIM
        signed email messages as invalid due to unknown algorithms.
        </t>
    </section>
    
    <section title="IANA Considerations">
        <figure><preamble>
        This draft defines the use of a new algorithm for DKIM. This draft updates the "DKIM Key Tag" registry
            to include the following new value:
        </preamble>
        <artwork>
          algorithm  |  mnemonic  |  Reference
        -------------+------------+--------------
         ECDSA P-256 |  ecdsa256  | This document
        
         
        </artwork>
        <postamble>
        The current DKIM Key Tag registry is located at https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml#dkim-parameters-6
        </postamble>
        </figure>
        <figure><preamble>
        This draft also defines a new hash algorithm for use with DKIM. This draft updates the
        "DKIM Hash Algorithms" registry to include the following new entry:
        </preamble>
        <artwork>
          algorithm  |  mnemonic  |  Reference
        -------------+------------+--------------
          SHA-512    |  sha512    | This document
        
        </artwork>
        <postamble>
        The current DKIM Hash Algorithm registry is located at https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml#dkim-parameters-7
        </postamble>
        </figure>
    </section>

</middle>

<!--  *****BACK MATTER ***** -->

<back>
    
    <references title="Normative References">
        <?rfc include="reference.RFC.2119" ?>
        <?rfc include="reference.RFC.5480" ?>
        <?rfc include="reference.RFC.6376" ?>
        <?rfc include="reference.RFC.8017" ?>
        <reference anchor="UTI.X680.2002">
            <front>
                <title>
                    ITU-T Recommendation X.680 (2002) | ISO/IEC 8825-1:2002, Information Technology - ASN.1 encoding rules:
                    Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules
                    (DER)
                </title>
                <author></author>
            <date year="2002" />
           </front>
            <seriesInfo name="ITU" value="X680" />
        </reference>
    </references>
    <references title="Informative References">
	<?rfc include="reference.RFC.7960" ?>
    <reference anchor="FIPS.186-4.2013" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">
        <front>
            <title>Digital Signature Standard</title>
            <author>
                <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="July" year="2013"/>
        </front>
        <seriesInfo name="FIPS" value="PUB 186-4"/>
    </reference>
    <reference anchor="NIST.800-57.2016">
    <front>
        <title>
            Recommendations for Key Management Part 1: General
        </title>
        <author>
            <organization>National Institute of Standards and Technology</organization>
        </author>
        <date month="January" year="2016"/>
    </front>
    <seriesInfo name="NIST" value="800-57"/>
    </reference>
    </references>

    </back>

</rfc>
