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