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