Re: Review of: draft-otis-dkim-harmful

[Douglas Otis <doug.mtview@xxxxxxxxx>]

On Jun 4, 2013, at 3:08 PM, Barry Leiba <barryleiba@xxxxxxxxxxxx> 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