On Mon, 2006-02-13 at 01:04 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > > DKIM security based on PRA would be a quite interesting point, to put > it mildly. It's possible if we're up to "fixing" (modifying) 2476bis > 8.1 and 2822, some "minor" details like re-charter DKIM left out. ;-)
This was an attempt to understand what strategy was being considered to arrive at the conclusions indicated in 4.1.4 and 4.1.5. It should not require a rechartering to suggest a defense that may utilize other mechanisms beyond that of DKIM. This was an attempt to review the details that lead to the Low impact conclusion. Block-listing email-addresses or signatures requiring a vastly larger database seems unlikely, when the signing-domain is the predominate identifier within all types of message replay abuse. 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. > > Why should major issues should be left unresolved, if only > > in theory? This is not the protocol draft. > > Sorry, a statement like "don't even think about DKIM without > PRA" sounds like a death sentence for me. For starters the > PRA is not necessarily (one of) the 2822-From address(es). Jim had mentioned Sender-ID for this purpose, where the speculation was to better understand his reasoning. 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. Forwarding or List-servers would not function with this type of strategy however. 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. > > The message path as described by SenderID > > JFTR, SenderID merely offers a normative reference to SPF for > this purpose. It contains no separate "description" of these > SPF-details except from "use spf2.0/TBD instead of v=spf1" and > the theoretical concept of "positional modifiers" (in practice > not one positional modifier exists so far). > > Four letters of one wannabe-backwards-compatible "spf2.0/TBD" > are the subject of an IAB appeal. 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. > > (when mediators are blocked) > > When they're blocked the replay attack wouldn't work, so that > is no problem with the idea to use PRA as a defense for DKIM. Correct. Blocking PRA mediators could prevent replay concerns, but at the loss of the functionality of mediators. Delayed acceptance was suggested as a means to bridge over this problem. -Doug _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
