ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: New Issue: Threat-00 Limiting the scope of trust

2006-02-12 18:48:33
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

<Prev in Thread] Current Thread [Next in Thread>