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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html