On Jun 4, 2013, at 3:08 PM, Barry Leiba <barryleiba(_at_)computer(_dot_)org>
wrote:
The draft continues to make broad, onerous claims like this, but provides
no documentation to indicate that the DKIM signing specification is flawed
in the function it is performing: attaching a validated domain name to a
message.
DKIM does not, in its current form, attach a validated domain name to a
message. By adding one line "MUST NOT validate a message with multiple
From:'s", DKIM will attach a validated domain name to a message.
Dear Barry,
Thank you for your response.
Here's the part of this I don't understand:
A DKIM signature does two things. It *does* attach a validated domain name
(the domain in the d= tag). And it tells the verifier what parts of the
message are covered by the signature (h= and l= tags). There is no claim in
DKIM that the d= domain has any relation to the RFC 5322 From. But the h=
tag does tell you how many From header fields are covered by te signature.
Of course it is incorrect for a DKIM signature to be valid when a message has
multiple From header fields. DKIM requires AT LEAST the From header field to
be the minimal portion of the message signed. Every other part of the message
is optional.
DKIM was intended not to require ANY change of other mail components. None.
When the DKIM signature is trusted and changes how the message is handled, it
would be wrong to suggest special consideration is then given other message
fragments. In addition, recipients will not see the signature header field nor
should they be expected to understand what it contains. They will see and
understand the From header field however.
Of course dkim=pass is placed in an Authentication-Results header where many
suggest this indicates the message has been "authenticated"!
Any verifier that wants to consider a message suspicious if the message
contains more From fields than are covered by the signature can do so, and
the DKIM spec does describe this situation.
DKIM does NOT score messages. Either the signature is valid or not. The spec
wrongly justifies allowing invalid repeated headers to result in a DKIM
signature verified as valid.
You would like the spec to REQUIRE that a message be considered suspicious
under those circumstances.
No. Just indicate the signature is NOT valid. This is the only sure way to
ensure trust is not misapplied and cause harm.
You made your case for this at least twice to the working group and at least
once more to the IETF community during Last Call of the draft that became RFC
6376. Your opinion wasn't agreed with: you were "in the rough". You're now
bringing it up a fourth time (at least), and you still appear to be in the
rough. The decision was to allow the verifier to decide how to handle this.
You and Dave Crocker made assurances this issue would not be abused. It is
being abused and NO other protocol layer ensures message structures are valid.
None. It was negligent for DKIM to ignore occurrences of highly deceptive
invalidly repeated header fields as it walks up and down the header field
stack. It is also wrong to suggest some other protocol layer handles this
checking. Such suggestion represents a waste of resources as ONLY DKIM should
determine signature validity which MUST consider invalidly repeated header
fields. It also appears most even expect DKIM signature validation checks
message structure, but this ONLY happens by double listing singleton header
fields in the signed header list. MOST domains don't bother with this ugly
hack, especially larger domains where checking message structure is critical.
Being in the rough doesn't make you wrong. But DKIM isn't wrong either, and
at some point you have to accept that you're standing alone, and accept the
consensus.
Putting people at risk in some race to obtain Standard status can not be
justified. Getting this right is far far more important. Allowing this to
become a standard will make specification modification even more difficult.
Regards,
Douglas Otis