STD76, DKIM is an Internet Standard, already has a Signer/Verifier
migration path in section 3.3 towards the higher key with backward
compatibility support for the verification of the smaller key.
Why remove 512 support from the verification side? Does this mean the
verifier will take valid 512 signature and make it invalid, no
signature message? Is there a correlation out there that 512 bits
signers are more prune to be Bad Guys? Spammers?
Lets also remember what the rest of STD76 section 3.3 says:
Factors that should influence the key size choice include the
following:
o The practical constraint that large (e.g., 4096-bit) keys might
not fit within a 512-byte DNS UDP response packet
o The security constraint that keys smaller than 1024 bits are
subject to off-line attacks
o Larger keys impose higher CPU costs to verify and sign email
o Keys can be replaced on a regular basis; thus, their lifetime can
be relatively short
o The security goals of this specification are modest compared to
typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on selecting key sizes.
IMO, this is all still true. It hasn't change. Has it?
--
HLS
On 5/12/2015 9:16 AM, MH Michael Hammer (5304) wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Martijn Grooten
Sent: Tuesday, May 12, 2015 3:23 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] DKIM Key Size Constraints
I propose a short draft that updates 6376 to say MUST use at least
1024 bits and setting that as the minimum size verifiers must be able
to validate. I'm volunteering to write it if people agree it's appropriate.
I think it is appropriate - and I agree with others that we shouldn't go
beyond
that.
Though why not make it even stronger and say that verifiers MUST (or
SHOULD, perhaps) consider signatures with keys shorter than 1024 bits
invalid? This makes it even more explicit.
+1
I think that Scott is correct in suggesting that this proposed update be
limited to setting the minimum size (and nothing else). I also like the
suggestion of considering anything smaller than 1024 invalid (Thank you
Martijn). This should be a quick and easy update.
Apart from that I think we should start a (separate) effort to determine
where we go from here. For the most part 2048 length keys seem not to be a
problem in the wild at this time. On the other hand, given the speed (or lack
thereof) involved in working groups generating useful output, if we start now
(for some definition of now) we should (hopefully) have a solution before
2048 keys are at risk.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html