On January 22, 2017 4:48:28 PM EST, 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?
In theory, sure. In practice it's just a variation on waiting for someone else to do the work. Additionally, DKIM will have an added burden of gaining community consensus that the security benefits of the change are important enough to break backward compatibility over. This is not a kind of decision the IETF is great at getting done with any rapidity. ARC, on the other hand, has no backward compatibility legacy to get caught by, unless we screw it up now. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
