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 protected]> 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=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5nzBQiwX1l4QDoE > 1glqw+93aMMp9hVVg8KYP3z43GTNScXda0mLAPoScWc1EHnm37TCdWj57F0CYjZhvs > X0EnkRpibYCEX/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 > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder [email protected] +1.415.793.5783
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
