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=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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
