Re: [ietf-dkim] DKIM Key Sizes

[Martijn Grooten <[e-mail]>]

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.

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