> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Mark Delany > Sent: Tuesday, October 19, 2010 5:53 PM > To: [email protected] > 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
