Re: [ietf-dkim] DKIM Key Sizes

[Eliot Lear <[e-mail]>]

Hi Dave,

I understand your despair, but even at the time we allowed for varying
key sizes precisely because we really didn't know how long people would
want to validate for, and we also didn't realize how real a crypto
attack on a dkim signature would be (Google found this problem out the
hard way).  You're precisely correct that when we see people saying that
somehow "John Podesta sent X" means "John Podesta said X" is not
something that DKIM was out to solve.  DKIM CAN'T solve that problem,
and if we attempt to architect it to do so, I'd recommend calling it
something else, because it surely will have very little to do with
Domain-based authentication.

For what it does, if people want to verify that the message came from a
given domain and the key remains valid, so long as the key size is
reasonable, there is some confidence that it will not have been hacked. 
Whether there is value in that is not a question we should even attempt
to answer, but if someone wants to produce keys of a larger length, so
long as it does not cause processing problems on the recipient end, I
don't see a problem.

Eliot


On 10/28/16 2:46 PM, Dave Crocker wrote:
> On 10/28/2016 2:37 PM, Eliot Lear wrote:
>> Hi Rolf,
>>
>>
>> On 10/28/16 2:28 PM, Rolf E. Sonneveld wrote:
>>
>>> An end user often cannot choose to sign or not to sign. The end user
>>> is dependent on what the ESP or the employers organization configures.
>>> Well, of course one could change ESP... But changing employer is quite
>>> a step ;-)
>>
>> The question then becomes this: what is the purpose of that signature?
>> How long should accountability last?  There is also the minor matter of
>> the operational complexity of rotating keys.
>
>
> Just to pour some salt into the wound of this topic:
>
>    DKIM is formally for the very narrow purpose of affixing an
> accountable identity/identifier to a message, where the proffered
> accountability is intentionally quite weak.  It doesn't claim to prove
> anything else.
>
>    It uses authentication crypto to do the affixing, and therefore it
> gets some data integrity as a side-benefit; it's meant to be
> short-term, but as long as the public key stays available, apparently
> it can work for longer-term, as we are seeing.  But really, it's
> purpose is not for the usual array of benefits that accrue with object
> signing.
>
>    However, we are consistently seeing people -- including folk
> attempting to offer technical guidance -- claim that DKIM does offer
> classic authentication benefits.  So, proof of data integrity; proof
> that the message came from the signer; and even proof that the
> contents are 'valid'.
>
>    Trying to educate people into the nuances of DKIM semantics has
> been almost completely useless, although some of us have been making
> vigorous efforts for 10 years.
>
>    I'm coming to think that we probably should stop fighting that
> battle and should, instead, make sure DKIM is does a worthy job of
> performing the functions people tend to assume it does.
>
> sigh.
>
> d/

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