Subject: [dmarc-ietf] ARC Minimum Key Sizes

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Jan 2017 15:30:58 -0500

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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Jan 2017 18:41:30 -0500

On Friday, January 20, 2017 03:30:58 PM Scott Kitterman wrote:
> 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

Moving John Levine's reply into this thread and then replying further:

On Friday, January 20, 2017 10:17:02 PM John Levine wrote:
> 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.
> 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=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4QDoE1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57F0CYjZhvsX0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjRCJ/ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y"
          "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+3sKqeH7tDbeXulzv102HP1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+yZGGz7RZEpNApv7pyBtfG0bz7cTwVX4QvP/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

---

From: Peter Goldstein <[email-masked]>
Date: Fri, 20 Jan 2017 16:08:32 -0800

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.

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:

>           "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4QDoE
> 1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57F0CYjZhvs
> X0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjRCJ/
> ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y"
>           "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+
> 3sKqeH7tDbeXulzv102HP1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+
> yZGGz7RZEpNApv7pyBtfG0bz7cTwVX4QvP/8MUQIDAQAB"
> )
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783

---

From: Brandon Long <[email-masked]>
Date: Sat, 21 Jan 2017 20:09:59 -0800

On Jan 20, 2017 4:08 PM, "Peter Goldstein" <[email-masked]> wrote:

Yeah, it turns out virtually all DNS registrars with website editors fail
to handle long TXT records as of about 6 months ago.

Brandon

Best,

Peter

On Fri, Jan 20, 2017 at 3:41 PM, Scott Kitterman <[email-masked]>
wrote:

>           "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4Q
> DoE1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57
> F0CYjZhvsX0EnkRpibYCEX/AZ2xLmwE7XcMXWWYjlUCK/BfFhuCUOEDbokjR
> CJ/ULbVUZfC8I8QZFdhqno987m26UhayLT3iNboj+v4mqUdYkVg6FmNRZRdDhxJYDSosT9j2Y"
>           "2eaSVsQ5Pvyt2ZzOjHJ9eXujw6/DKR2WGVEIIX+3sKqeH7tDbeXulzv102H
> P1fmoE6sKgPRevIHKoMfFagNyXXkqxmyRY/jV+yZGGz7RZEpNApv7pyBtfG0
> bz7cTwVX4QvP/8MUQIDAQAB"
> )
>

-- 

Bringing Trust to Email

[email-masked]
+1.415.793.5783 <(415)%20793-5783>