Re: [ietf-dkim] DKIM Key Sizes

[Peter Goldstein <[e-mail]>]

>
> 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 <[e-mail]
> 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

[e-mail]
+1.415.793.5783

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html