Subject: Re: [dmarc-ietf] ARC Minimum Key Sizes

From: Scott Kitterman <[email-masked]>
Date: Fri, 03 Feb 2017 13:40:50 -0500

Top posting since the quoting seems hopelessly confused.

Here is a specific proposal (unified diff and rfcdiff attached).  I liberally 
borrowed text from RFC 6376 to minimize the novelty of the proposal.  The ARC 
draft already references RFC 6376, section 3.6, so I don't think we need 
another reference specifically to 3.6.2.2 to talk about how to concatenate TXT 
strings.

I did not attempt to cover algorithm agility or define an additional algorithm 
beyond SHA 256.  Whatever the next algorithm is, I think it needs to apply to 
both DKIM and ARC, so it's out of scope.  I think the issues associated with 
ARC chains using different algorithms should be addressed, but I'm hoping the 
clearer proposal that John Levine mentioned[1] will address that.

Scott K

[1] <[email-masked]>

On Saturday, January 21, 2017 08:09:59 PM Brandon Long wrote:
> On Jan 20, 2017 4:08 PM, "Peter Goldstein" <[email-masked]> wrote:
> 
> I think Scott's point about operational options is well taken.  Google ran
> into some operational issues with some DNS vendors when they attempted to
> make all new G Suite DKIM keys 2048 - they rolled back to making 2048 bit
> keys the default, but allowing 1024 bit keys as an option.
> 
> 
> Yeah, it turns out virtually all DNS registrars with website editors fail
> to handle long TXT records as of about 6 months ago.
> 
> Brandon
> 
> 
> The MUST/SHOULD language suggested makes sense.  And we definitely don't
> need to roll out new protocols using SHA-1.
> 
> I would suggest some related language for verifiers.  Something like what's
> found in the DKIM spec, but with updated bit sizes:
> 
> Verifiers MUST be able to validate signatures with
>    keys ranging from 1024 bits to 4096 bits, and they MAY be able to
>    validate signatures with larger keys.
> 
> At a minimum I think we should require verifiers to be able to support 4096
> bit keys (and potentially 8192 bit).  There's no reason verifiers shouldn't
> be able to support longer key sizes, and this adds some future proofing to
> the specification.
> 
> Best,
> 
> Peter
> 
> On Fri, Jan 20, 2017 at 3:41 PM, Scott Kitterman <[email-masked]>
> 
> wrote:
> > On Friday, January 20, 2017 03:30:58 PM Scott Kitterman wrote:
> > > On Friday, January 20, 2017 you wrote:
> > > > On 01/20/2017 11:23, Scott Kitterman wrote:
> > > > > I'm not on the ARC list, so I'll pile on this thread here...
> > > > 
> > > > This is the right place for anything constructive regarding the
> > > > specification, so no problem regarding any other lists.
> > > > 
> > > > > I understand the minimum key size in the draft is 512 bits.  I'm not
> > > > > planning
> > > > > on releasing any software that supports key sizes less than 1024, so
> > 
> > I
> > 
> > > > > guarantee you interoperability problems for small keys.
> > > > 
> > > > +1 -- no need for weak keys.
> > > > 
> > > > 1) Do we have a normative reference within the RFC framework for key
> > > > lengths for different crypto systems, and can we simply invoke that
> > > > reference rather than including a hard figure in this spec?
> > > > 
> > > > 2) Does such a reference still consider 1k keys as acceptable at this
> > > > time? Is there a schedule for periodic review?
> > > > 
> > > > --S.
> > > > 
> > > > +++1 wrt Scott's comment about 512 bit keys.  We inherit this
> > 
> > requirement
> > 
> > > > from the DKIM spec, but imho it is not reasonable.  If this is worth
> > > > discussing, perhaps we should move it to another thread?
> > > > 
> > > > Regards,
> > > > =Gene
> > > 
> > > OK, Since I wasn't off topic after all, here's a new thread...
> > > 
> > > I believe we've looked for such a reference before and not found a good
> > 
> > one.
> > 
> > > The IETF BCP is from 2004: https://tools.ietf.org/html/rfc3766
> > > 
> > > Operationally, 1024 is the minimum key size recommendation I generally
> > 
> > see
> > 
> > > for DKIM today.  NIST recommends 2048 bits, SHA-256 only for US
> > > goverment
> > > use [1].
> > > 
> > > 
> > > Scott K
> > > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.
> > 
> > SP.800-177.pdf
> > 
> > Moving John Levine's reply into this thread and then replying further:
> > 
> > On Friday, January 20, 2017 10:17:02 PM John Levine wrote:
> > > >1) Do we have a normative reference within the RFC framework for key
> > > >lengths for different crypto systems, and can we simply invoke that
> > > >reference rather than including a hard figure in this spec?
> > > 
> > > There's RFC 3766, but it's over a decade old and has rules for how to
> > > figure out how long a key you need, not the actual sizes.
> > > 
> > > This NIST publication seems relevant:
> > > 
> > > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.
> > 
> > SP.800-57pt1r4.pdf
> > 
> > > The tables on pages 52 and 53 suggest that we use 2K keys and sha256
> > 
> > hashes.
> > 
> > > >2) Does such a reference still consider 1k keys as acceptable at this
> > > >time? Is there a schedule for periodic review?
> > > 
> > > No.  See the document.
> > > 
> > > R's,
> > > John
> > 
> > Large keys like 2048 present other potential operational problems.  Here's
> > a
> > 2048 bit, sha-256 key record:
> > 
> > default._domainkey      IN      TXT     ( "v=DKIM1; h=sha-256; k=rsa; "
> > 
> >           "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4Q
> > 
> > DoE1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57
> > F0CYjZhvsX0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjR
> > CJ/ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y"
> > 
> >           "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+3sKqeH7tDbeXulzv102H
> > 
> > P1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+yZGGz7RZEpNApv7pyBtfG0
> > bz7cTwVX4QvP/8MUQIDAQAB"
> > )
> > 
> > I'm sure that will get line wrapped into illegibility, so I'll make the
> > actual
> > point:  It's longer than will fit in a single TXT string.  While there is
> > nothing wrong with that from a DNS standards or even a core DNS
> > operational
> > perspective, it is not rare that DNS provisioning systems don't support
> > this.
> > I don't want to make it so secure it's deployability is severely hampered.
> > 
> > I would suggest MUST at least 1024 bit, SHOULD 2048 bits.  I think MUST
> > sha-256 is also a good idea.  Approximately the last thing we should be
> > doing
> > now is rolling out new protocols using sha-1.
> > 
> > Scott K
> > 
> > _______________________________________________
> > dmarc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dmarc
--- arc.old	2017-02-03 13:13:41.096992188 -0500
+++ arc.new	2017-02-03 13:30:46.897018539 -0500
@@ -86,6 +86,7 @@
        5.2.1.  Handling Violations in the ARC Sets . . . . . . . . .  12
      5.3.  Key Management and Binding  . . . . . . . . . . . . . . .  12
        5.3.1.  Namespace . . . . . . . . . . . . . . . . . . . . . .  12
+       5.3.2.  Key Sizes . . . . . . . . . . . . . . . . . . . . . .  13
    6.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
      6.1.  Participation . . . . . . . . . . . . . . . . . . . . . .  13
      6.2.  Relationship between DKIM Signatures and ARC Headers  . .  13
@@ -327,7 +328,8 @@
    affect the validity of the header.
 
    o  a = hash algorithm; syntax is the same as the "a=" tag defined in
-      Section 3.5 of [RFC6376];
+      Section 3.5 of [RFC6376], but only the only valid algorithm is
+      currently defined for ARC is "rsa-sha256";

@@ -679,6 +681,33 @@
    the public key will a query at the name
    "foo.bar._domainkey.example.com".
 
+5.3.2.  Key Sizes
+
+
+   Selecting appropriate key sizes is a trade-off between cost,
+   performance, and risk.  Since short RSA keys more easily succumb to
+   off-line attacks, Signers MUST use RSA keys of at least 1024 bits.  Verifiers
+   MUST be able to validate signatures with keys ranging from 1024 bits to 4096
+   bits, and they MAY be able to validate signatures with larger keys.  Verifier
+   policies may use the length of the signing key as one metric for determining
+   whether a signature is acceptable.
+
+   Factors that should influence the key size choice include the
+   following:
+
+   o  The practical constraint that large (e.g., 4096-bit) keys might
+      not fit within a 512-byte DNS UDP response packet
+
+   o  Larger keys impose higher CPU costs to verify and sign email
+
+   o  Keys can be replaced on a regular basis; thus, their lifetime can
+      be relatively short
+
+   o  The security goals of this specification are modest compared to
+      typical goals of other systems that employ digital signatures
+
+   See [RFC3766] for further discussion on selecting key sizes.
+
 6.  Usage
 
    For a more thorough treatment of the recommended usage of the ARC
@@ -1234,6 +1263,10 @@
 Internet-Draft                ARC-Protocol                 December 2016

+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strengths For
+              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
+              RFC 3766, April 2004.
+
    [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
               Code: The Implementation Status Section", RFC 6982,
               DOI 10.17487/RFC6982, July 2013,