-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Tuesday, October 19, 2010 5:53 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] double header reality check
Any filter or agent that makes any kind of filtering, routing or
sorting decision based on any header field which in turn presumes
there's only one such field without actually checking is a potential
security concern.
I think this is a subtely different problem though.
All of the examples you cite (and all other pre-DKIM examples for that
matter) are foolable with a single forged header today. That they
could be further fooled with multiple headers is not an issue.
In a future world where such tools (and UAs) could act with authority
because DKIM has assured the headers/payload is where we have the
problem.
Only once tools and UAs take advantage of DKIM, do these attacks
become relevant. That's why I think this is a DKIM problem. We are
wanting tools and UAs to take advantage of DKIM but by doing so they
are possibly making themselves more vulnerable to attackers.
[...]
IOW. Asking them to rely on DKIM is a backward step.
I do understand the difference. And I am not ignorant to the fact that any
mail system component that's offered some new trust mechanism which has
inherent exposure risks is not likely to adopt that mechanism anytime soon.
Plenty of examples exist, even in the email space, some of them fairly recent.
The job of a designer of such a mechanism (or any mechanism really) is twofold:
(a) reduce risks as much as is practical, and (b) fully expose those that
remain. Both of these are easily accomplished by a specification that is clean
and thorough. Anyone who's shipped a product that can be tough to use knows
that complete user documentation of the issues makes even a tricky product
palatable to customers. Forewarned is forearmed.
I think a lot of this discussion conflates protocol specification with
implementation. I'm focused on the former. I maintain that including wording
intimating that a DKIM implementation is non-compliant if it fails to do mail
format validation prior to accepting input or returning a result causes the
specification not to be clean. It's a layering violation. It's sloppy design.
It shouldn't be done.
The difference may be as subtle as what you're talking about above. For
example, although I am arguing that RFC4871bis shouldn't contain any kind of
normative enforcement of other specifications, my own open source
implementation already does it and has almost since day one. I think that's
the right thing to do, not because RFC4871 told me to, but because RFC5322 did.
And as a result, it's in the part of the code that deals with mail, not the
part that deals with DKIM.
It also does all kinds of validation that the data it got back from the
nameserver on a key or policy query conforms to the expected format of a DNS
query described in RFC1034, because if it doesn't (which does happen sometimes,
four so far today in the logs) then running with those bits can have nasty side
effects. But RFC4871 doesn't, and shouldn't, require that checking. That
syntax is defined in RFC1034.
Or are you folks also saying we should add text to RFC4871bis mandating
validation of the results returned by functions like res_send()? Suppose a
chthonic hacker could send DKIM-signed mail that causes his DNS server to be
queried, returning a reply that will somehow always validate (or crash). And
suppose res_send() doesn't validate the payload, only passes it through to the
caller. Isn't this just as dangerous?
We are most certainly obliged to emphasize to consumers of DKIM output the
distinction between what was covered by a signature and what was not, and lay
out the possibility that such consumers could be confounded in the way that's
been described. Failing to do so is a disservice. I'm all for putting that
into Security Considerations in intricate detail with lots of examples of
possible exploits. That, to me, is precisely why that section is mandated as
part of all RFCs. I will happily write a sesquipedalian treatise on this topic
to be included there if it resolves this issue.
An aircraft comes with an operating handbook. The manufacturer goes to great
pains to make the aircraft as safe and secure as possible. Ultimately, though,
it's the pilot that crashes or lands, and thus learns the ins and outs of that
particular aircraft by reading the ample documentation provided by the
manufacturer before taking to the air.
No, Doug, I don't think these checks belong in POP3, or IMAP, or SIEVE. They
belong in whatever component is the one that decides when or whether seek or
apply a DKIM result. Like I said before, it should be perfectly reasonable for
a protocol specification to require something proper from the layers below it,
and to require of itself that it only hands something valid to the layers above
it.
Validating mail syntax belongs in the specification for the mail components and
DKIM work belongs in the DKIM components. Anything else makes as much sense to
me as asserting that an MTA/MUA/whatever should only invoke a DKIM verifier
after confirming that the DKIM-Signature header field conforms to what RFC4871
says. I would find that equally incorrect, and for the very same reasons.
There has been talk of applying DKIM to technologies like Usenet and HTTP
output. Packing DKIM with mail-specific verification requirements could
prevent such things from happening. Shall we also add a "but only when used in
the email context" clause?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html