On Sun, Jan 22, 2017 at 1:18 PM, Scott Kitterman <skl...@kitterman.com> wrote:
> > On January 22, 2017 3:30:14 PM EST, Kurt Andersen <ku...@drkurt.com> > wrote: > >On Sat, Jan 21, 2017 at 4:39 PM, Peter Goldstein <pe...@valimail.com> > >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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
