On 10/20/10 10:55 AM, Murray S. Kucherawy wrote: > 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.
Disagree. Since DKIM /REQUIRES/, at minimum, the From header field be signed, are you suggesting layer violations when DKIM's verification process checks for non-compliant multiple From header fields? It would be negligent of DKIM not to return a result of PERMFAIL when multiple From header fields are detected. Clean layering of a verification process is /not/ achieved when consumers of DKIM results must re-examine messages that receive a PASS result. RFC5322 Section 6.4 amends the compliance required by SMTP, and removes strict enforcement. There is not even a clearly defined error code to report non-compliance. Since no layer below DKIM assures RFC5322 compliance, it is negligent for the DKIM verification process to skip checks for multiple From header fields. DKIM extends trust based upon the signing domain to include the From header field, as a minimum. Since normally there is no advantage obtained by introducing multiple From header fields without the additional trust established by DKIM, it becomes fully incumbent upon DKIM to check for illegal conditions that might lead to erroneous placement of trust. Failure in this regard is likely to result in trust related exploitations. > 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. Disagree. DKIM MUST detect conditions that would allow trust established by DKIM to be exploited, where DKIM, at a minimum, includes the From header field. Specifying a DKIM result for multiple From header fields impacts ONLY consumers of DKIM results. This is not about enforcing RFC5322 compliance, this acknowledges that many processes assume there will be only a single From header field, as required by RFC5322. Violation of this expectation prevents any DKIM status other than PERMFAIL to be safely returned. > 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. DKIM Section 3.2 requires that tags with duplicate names *MUST NOT* occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is to be considered invalid. Because many had trouble with the format specified in Section 3.2 for tag values that are space delimited, many did not want to use the colon delimited structure specified in section 3.6.1. Now many have decided to list the t= tag twice when adding the t=y value. A similar problem also exists with the g= tag. It is ironic that DKIM is having trouble ensuring strict format compliance for these unique DNS resource records. RFC1034 clearly indicates valid results without expecting the consumers of DNS to second guess their validity. However DKIM requires use of TXT resource records that are not required by SMTP. An intrusion into DNS that is also being overlooked. DKIM also specifies RFC3833 which warns against name chaining that also impacts the operation of DKIM validation. > 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? How would changing DKIM mitigate this type of threat? > 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. Disagree. DKIM ALWAYS includes the From header field! It would be a disservice to expect consumers of DKIM results to involve themselves in the same intricacies currently handled by the DKIM verification process. By providing the correct results, no second guessing (layer violation) would be needed. [] > 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. What component? How many of these "whatever" components need to be updated to mitigate use of multiple From header field exploitations of the trust established by DKIM? Won't this be asking them to make the same checks that the DKIM verification process should have made? > 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. So you expect SMTP will now start strictly enforcing RFC5322 compliance just to retain the integrity of DKIM results? IMHO, this would not be a realistic expectation. > 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. RFC5321 does not mandate strict RFC5322 compliance! It never has, and likely never will. Since DKIM, at a minimum, binds the DKIM domain with the From header field, it remains critical from a security standpoint that DKIM not offer PASS results when there are multiple From header fields! > 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? Disagree. Whenever results might be ambiguous and thus exploited, PASS should not be returned. This rule would be equally true for any message format. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
