Douglas Otis wrote: > It should not require a rechartering to suggest a defense > that may utilize other mechanisms beyond that of DKIM.
If that "other mechanism" is SPF we're in the muddy waters of "downref". DKIM wants to be PS. SPF is only "experimental". If that "other mechanism" is PRA it's even worse, state of the art is that it can't advance on standards track as is, compare <http://www.ietf.org/IESG/APPEALS/appeal-response-william-leibzon.txt> | It would be inappropriate to advance Sender-ID on the | standards track without resolving this interoperability | problem. To resolve this problem we'd have to modify 2476bis and 2822. The former is simple, but removing a MUST from 2822 is tricky. BTW, I'd support the latter. > Assuming that the signature is being used as a basis of > acceptance, the likely block-listing of the signing-domain > would create a High impact. At the moment threats-00 has LOW impact with M/H likelihood for 4.1.4, and LOW impact with HIGH likelihood for 4.1.5. For the likelihood that's okay: 4.1.4 is more difficult for the bad actors. And for 4.1.5 the impact might be lower than 4.1.4, probably depending on the 4.1.5-message. Any HIGH / HIGH is a showstopper, we can't have a HIGH / HIGH without clear recipe to prevent it. And "just use PRA" is not convincing. If PRA would work in practice we don't need DKIM. > Jim had mentioned Sender-ID for this purpose But PRA is often different from the 2822-From, it's unrelated to signing domains. Maybe it helps with a propoer subset of STRONG signing policies. Similar reasoning for SPF. In both cases mainly "closed" (either PASS or FAIL) policies. NEUTRAL for "the rest of the world" (as in ?all) can't be good enough. > Even this brief review was not limited to just Sender-ID as a > path solution, but also included a list of HELOs that could > describe the same path in one or two lookups. Okay, covering "signing domains" by sets of related HELOs makes more sense than PRA or MAIL FROM. We've nothing for arbitrary HELO id.s. At best we have CSV's zone-cut emulation. But CSV like all the others is single-hop (MON to MX), attackers won't use a CSV or SPF protected HELO, they simply pick another HELO. > Forwarding or List-servers would not function with this type > of strategy however. Yes. And receivers usually don't know what the client is, they have to assume that it's some kind of mediator. Especially a mediator that does _NOT_ support SPF / PRA / DKIM. > This loss of normal functioning would be a significant > trade-off, where the use of delayed acceptance was offered as > a possible means to mitigate the inability for a path > approach to otherwise deal with mediators. One argument _for_ DKIM is, that using SPF behind 1123 5.3.6(a) won't work. For PRA it's the complete 1123 5.3.6, not only (a) If we'd now find that DKIM needs SPF (or PRA) that's a bit odd: >> It makes no sense to base DKIM security on PRA, neither >> technically nor procedurally. > While sharing many of the same concerns, the review was an > attempt to understand what Jim was considering, not to > endorse any mechanism. Okay - on the SPF list Scott and I just discuss SPF modifiers to get a grip on this mess, ideas like "dkim=strong" (or weak) and maybe some "op=from" (2821- and 2822-From always equal). But I don't see any general solution wrt "DKIM replay attacks" in these ideas yet. DKIM is supposed to work on its own. If we get the complete mix of SMTP and 2822 again, that's back to square one, MARID. <shudder /> Bye, Frank _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
