-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Steve Atkins
Sent: Sunday, October 24, 2010 9:54 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
1) During the handling of a message in conjunction with a DKIM result
that indicates a valid signature, consider as valid only those fields
and the body portion that was covered by the signature. Note that this
is not to say unsigned content is not valid, but merely that the
signature is making no statement about it.
There are a couple of issues with this. First, it implies that if a
DKIM signature does cover a header, then that DKIM signature is saying
that that header is "valid", which isn't the case in general.
Ah right. Need to be meticulous here.
How about:
1) During the handling of a message in conjunction with a DKIM result that
indicates a valid signature, observe the distinction between those parts of the
header and body that were covered by the signature and those that were not.
Note that this is not to say unsigned content is not valid, but merely that the
signature makes no statement about it.
Second, this is nearly meaningless operationally. for the sort of
attack that's been envisioned (showing different author or subject in
an apparently signed message), as there's no real way to consider any
particular field as valid or invalid (unless you're communicating the
information all the way to the MUAs display code, or you're deleting
headers in transit - which are both possibilities, but ones that would
need to be called out explicitly).
The text is intended to be generic, referring to any entity that might consume
a DKIM "pass" result. The particularly interesting ones are of course the MUAs
and anything that does authentication of a service (e.g., an MLM) based on a
signed field, but I was trying to avoid talking about them specifically.
2) Refuse outright to sign or verify any message that is not
syntactically valid.
This is overly strong, as a lot of messages that are not 5322 valid are
wanted (bare linefeeds, amongst other issues). Encouraging signers or
verifiers to deny the existence of a DKIM identity in those cases just
makes it harder to distinguish between wanted invalid mail and unwanted
invalid mail.
This is the informative equivalent of the normative SHOULD/MUST upon which
people were insisting. If you think it would help, we could call out
specifically 3.6 of 5322, but the risk there is that people will harden against
that vector only to have something else come up later that we didn't call out
specifically.
Something that's more to the point we're concerned about might be more
like "A mail system that considers DKIM signatures during mail delivery
should treat with suspicion any email that has multiple copies of any
header where RFC 5322 requires they have no more than one, as it may be
an attempt to replay a DKIM signed message with different content. DKIM
verifier implementors may consider messages that are malformed in this
way as unsigned."
Maybe that can be some example-type text tacked on to the second bullet point?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html