On Oct 24, 2010, at 10:15 PM, Murray S. Kucherawy wrote:
-----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.
That still expands the API from the DKIM verifier quite a lot - it requires the
verifier to explicitly list which headers are signed, and which aren't (that
the h= field doesn't do that is what we're having problems with). It would also
require that to be pushed all the way downstream to other pieces of software,
perhaps via something similar to an extended Authentication-Results type of
header.
That's not impossible, but seems very complex for the specific problem we're
considering - we just need to communicate "This message violated 5322,
specifically in a way that makes us think the sender is trying to game DKIM"
(either by flagging the mail as syntactically invalid and suspicious at some
point in the mail stream, or invalidating the DKIM signature).
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.
If we need to communicate a list of "valid" headers to downstream consumers of
a DKIM "pass" result it's a lot more complex than a simple pass/fail and we'd
need to consider what that API might be (partly so we're clear on what data in
addition to a "DKIM pass, here's your d=" we're communicating).
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.
Yup. It's a backdoor SHOULD, and I don't like it for the same reason :).
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.
I'm more concerned with the suggestion that *any* violation of 5322 (or 2045
and friends - it's all syntax) is grounds for refusing to validate a message. I
think that DKIM verifiers refusing to pass on a d= identifier due to trivial
format violations is likely to reduce the quality of the mailstream rather than
increase it.
(Those violations may well be grounds for another part of the mail handler to
reject the mail altogether, but that's outside DKIMs main job of providing an
identifier to help the downstream mail handlers make informed decisions.)
Focussing on just those issues that may affect the DKIM security model (which,
if we kill off l=, is likely to just be adding unsigned headers) seems like
it'd push implementors in a more useful direction.
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?
Could be. Something a bit more specific would help implementors.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html