[ietf-dkim] Final update to 4871bis for working group review
vesely at tana.it
Thu Jul 7 04:55:59 PDT 2011
On 06/Jul/11 20:34, Murray S. Kucherawy wrote:
> Anyway, with a few nitty edits from me as well, here's the current
> 8.15 for -15 for everyone's consideration.
A few comments:
> 8.15. Attacks Involving Extra Header Fields
> Many email components, including MTAs, MSAs, MUAs and filtering
> modules, implement message format checks only loosely. This is done
> out of years of industry pressure to be liberal in what is accepted
> into the mail stream for the sake of reducing support costs;
> improperly formed messages are often silently fixed in transit,
> delivered unrepaired, or displayed inappropriately (e.g., by showing
> only one of multiple From: fields).
I'd s/to be liberal/to be exceedingly liberal/ (we don't want to
revise Postel's statement, do we?)
> A genuine signature from a domain under attack can be obtained by
> legitimate means, but extra header fields can then be added, either
> by interception or by replay. In this scenario, DKIM can aid in
> detecting addition of specific fields in transit. This is done by
> having the signer list the field name(s) in the "h=" tag an extra
> time (e.g., "h=from:from:..." for a message with one From field), so
> that addition of an instance of that field downstream will render the
> signature unable to be verified. (See Section 3.5 for details.)
> This in essence is an explicit indication that the signer repudiates
> responsibility for such a malformed message.
+1 for exemplifying "h=from:from:...", even if it's not a cure-all.
> DKIM signs and validates the data it is told to and works correctly.
> So in this case, DKIM has done its job of delivering a validated
> domain (the "d=" value) and, given the semantics of a DKIM signature,
> essentially the signer has taken some responsibility for a
> problematic message. It is up to the identity assessor or some other
> subsequent agent to act on such messages as needed, such as degrading
> the trust of the message (or, indeed, of the signer), or by warning
> the recipient, or even refusing delivery.
I'd omit any allegation on what an assessor's needed actions might be.
(Actually, we'd need yet another policy or authentication method in
order to allow the outcome of an identity assessor to be formally
expressed. Without it, the quick-n-dirty approach of degrading the
trust of a message by tampering with its DKIM verification's results
may seem the easiest remedy --much like what Doug et al. proposed.)
> An agent consuming DKIM results needs to be aware that the validity
> of any header field, signed or otherwise, is not guaranteed by DKIM.
Please, s/validity/reliability/: someone might believe a field is
valid if it retains the value that was given to it originally.
More information about the ietf-dkim