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
<martijn(_at_)lapsedordinary(_dot_)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
peter(_at_)valimail(_dot_)com
+1.415.793.5783
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html