Kurt, I agree that the best approach would be to update the DKIM spec to reflect modern cryptographic realities.
I actually broached this topic on the IETF DKIM mailing list a couple of months ago. The thread quickly evolved into a discussion about using even shorter key sizes (768 bit) to avoid the long term verifiability of emails, and address associated privacy concerns. There did not seem to be a lot of support for raising the bit size requirements. That said, perhaps others would have more success. If we can drive this change to RFC 6376, that would be great. If not, I think it's important that we make appropriate cryptographic recommendations for ARC. Not only because of the security implications, but also because I can't imagine that ISPs that don't currently accept DKIM keys smaller than 1024 bits (e.g. Google) will accept ARC signatures with such keys. It needs to be made clear somewhere - the RFC, the usage guide, wherever - that 512 bit keys just won't work. There's a similar issue around the use of SHA-1. How would you suggest we drive a revision to RFC 6376 to address this issue? Thanks. Best, Peter On Sun, Jan 22, 2017 at 1:48 PM, Kurt Andersen <[email protected]> wrote: > On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman <[email protected]> > wrote: > >> >> On January 22, 2017 3:30:14 PM EST, Kurt Andersen <[email protected]> >> wrote: >> >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein <[email protected]> >> >wrote: >> > >> >> >> >> . . . ARC . . . inherits . . . from the DKIM RFC. The DKIM RFC >> >explicitly >> >> requires verifiers to validate signatures with bit sizes ranging from >> >512 >> >> bits to 2048 bits. >> >> >> >> There is a separate effort going on in the context of the UTA working >> >group to address technologically obsolete encryption strength >> >recommendations that have appeared over time in a variety of different >> >RFCs. I don't think that adding yet another independent reference is a >> >good >> >idea and I am strongly opposed to trying to torque the ARC requirements >> >to >> >be different from DKIM. >> > >> >If Scott is planning to make dkimpy non-conformant to the DKIM spec, I >> >think that is regrettable, but I don't see that making the problem >> >worse with ARC "going its own way" helps anyone. >> > >> >--Kurt >> >> No responsible operator has used the RFC minimum DKIM key sizes for a >> long time. They were trivial to bypass half a decade ago. No one has ever >> complained about 1024 bits default minimum being too big. I did once get a >> complaint about the Debian opendkim package suggesting the minimum should >> be 2048 bits. >> >> Maybe some other working group will accomplish something someday is not a >> good reason to perpetuate obsolete crypto in this one. >> >> Scott K > > > I agree with your points, but don't you think it would be better to "fix" > the DKIM spec than to have ARC "do its own thing" which does not address > the weakness still enshrined in the DKIM spec? > > --Kurt > > _______________________________________________ > 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
