> > As for the original question, I agree that longer keys should be > supported as a matter of principle. But before we end up with an RFC > that makes implicit promises about what receivers can handle that don't > match reality, does anyone have an idea whether receivers can handle > key sizes larger than 2048 bits in practice? (I know the maths is the > same, but it'd make sense to set some kind of upper limit to avoid > getting DoS'ed and for all I know, people may have set that limit to be > 2048 bits.)
This is certainly a fair point. I raised the issue with representatives of one of the big U.S.-based receivers, and they indicated that they can accept keys at least up to 4096 bits. But it's probably worth setting up a test mail server and validating the behavior with assorted receivers. I can look into doing that. It's also probably worth ensuring that the major open source DKIM implementations support both signing and verifying with 4096-bit keys. Aside from OpenDKIM and dkimpy, are there any others that should be checked? Best, Peter On Sat, Oct 29, 2016 at 9:26 PM, Martijn Grooten <mart...@lapsedordinary.net > wrote: > On Fri, Oct 28, 2016 at 11:06:34AM +0100, Stephen Farrell wrote: > > Instead, I'd point out that this can be handled, even now, > > by simply rolling to a new key and then shortly publishing > > the private key used to sign the messages. That way Podesta > > could deny the content once more, at least at the crypto > > level. > > (...) > > > I could imagine us writing an RFC about why and how to do > > DKIM signature key rollover and private key publication and > > would be happy to help if there were a chance it'd get some > > traction. > > I think this is a really neat solution and I'd love to see an RFC like > this. In theory, that is. > > In practice, I think that plausible deniability is something that > concerns very few people outside the crypto community. Maybe there is a > need for such an RFC among the modern day Lavabits, and if that is the > case it would be great if we could contribute, but I would expect people > running such services to understand their complex threat models quite > well already. > > As for the original question, I agree that longer keys should be > supported as a matter of principle. But before we end up with an RFC > that makes implicit promises about what receivers can handle that don't > match reality, does anyone have an idea whether receivers can handle > key sizes larger than 2048 bits in practice? (I know the maths is the > same, but it'd make sense to set some kind of upper limit to avoid > getting DoS'ed and for all I know, people may have set that limit to be > 2048 bits.) > > Martijn. > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJYFPfJAAoJEI5dMs9dIv8Z/SUH/jAe2uvRQ26D+/rEAMLRbsKP > Bc8/SPsYH2lEKEf9w2xljTbRyP6M6puUFZsciPTq7v44L7Giov0gvdcDzDVVfL/A > 71yZD7abViSqIbIvcAvh0yWtWF8oRv8oOfivcGdoOaDec+zTgS0FnEyBhyA70lJC > W0pbIm8RvFCwKPjVMuFQ1mElFnSPoi0PPwP6HEpFXdtnqwfVOPWfcMfnBns6HlnR > ymwCkiYL1z/i/A5P8Gj3VknwtwJxvuOQUYjB+iZVaHDiANlSAnU0MdTSkVenKeBH > FYe8l3sEYk8NTxoJK+Z1iJ+LwasOg8qztZOimP4MMrED+5RnLfdwMQk5bDzClJw= > =3yQ1 > -----END PGP SIGNATURE----- > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder pe...@valimail.com +1.415.793.5783
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
