On 09/Nov/10 03:05, John R. Levine wrote:
"Signers SHOULD take reasonable steps to ensure
that the messages they're signing are valid according to [RFC 5322,
etc]." Leaving the definition of "reasonable" out allows flexibility. It
may be waffly, but I like the approach in this case.
This is OK, but it misses the scenario where a bad guy takes an existing
signed message and prepends another Subject: or From: header. It's more
effective to address this in the verifier.
I'd agree on the effectiveness of that approach from a software design
POV only. Designing specifications may involve different
considerations...
3. It'd be reasonable for the DKIM spec to remind verifiers that
signers aren't supposed to sign stuff like this, so they might
consider that when deciding what to do with it after verification.
It'd be reasonable to remind them of this particular case. But
I think that all ought to be informative text.
I don't feel strongly about how normative we make the language, but I do
think it would be a good idea to encourage verifiers not to say the
signature is valid on a message with extra headers, even if it
mechanically verifies. This catches both the sloppy signer and the
hostile intermediary.
FWIW, my DKIM verifier has for several weeks rejected anything which has
an extra of any of these [omitted] headers:
Thanks for putting it that way, John. It makes it easier to clear the
issue: I think everybody agrees that DKIM specifications say nothing
about rejecting. Therefore, John's software is called a "DKIM
verifier" somewhat improperly. It /includes/ a DKIM verifier, but
also acts as a band-pass message filter.
IMHO, strong feelings about this issue come up from misunderstandings
about these roles. On the one hand we have a normative definition of
the mechanical properties of signatures. On the other hand we want to
deal with MTA behavior, since that is the mechanism's semantics. One
problem of tackling both topics within the same document is that
making normative statements about MTA behavior may result in confusion
between semantic validation and mechanical verification.
At this point I would rephrase the third paragraph of Murray's "Take
two" for 8.14 Malformed Inputs, as follows:
Because of this, DKIM implementations for MTAs are strongly advised
to couple with message filters who can complement their MTA's native
checks and reject or treat as suspicious any message that has
multiple copies of header fields that are disallowed by section 3.6
of [MAIL], particularly those that are typically displayed to end
users (From, To, Cc, Subject). A signing module could return an
error rather than generate a signature; a verifying module might
return a syntax error code or arrange not to return a positive
result even if the signature validates according to normative DKIM
specification.
However, referring to another document --either ADSPbis or
draft-kucherawy-mta-malformed-- may allow for stronger and clearer
language. For example, setting "dkim=fraud" in an A-R field would not
be confused with broken signatures like "dkim=fail (technically pass)".
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html