Douglas Otis wrote:
The DKIM/ADSP DDoS concern is analogous to that of Sender-ID.
ADSP needs at most one DNS query for an existing domain, there
is no "analogy" to spf2.0/pra. If you are worried about a From
header field with hundreds of addresses below a victim domain
we write "don't do this" in the ADSP security considerations.
Briefly, Sender-ID enables an exploit for bad actors that are
able to influence the PRA.
Doug, that's all fine, and if you want several MBs of arguments
against RFC 4406 you know where to find them, www.openspf.org
and the IAB appeal come to mind. So far none of the ADSP drafts
says "updates: 4406", writing a 4406bis isn't in the WG Charter,
only Murrays's Auth-header draft does as much as reference 4406
(IMO correctly, YMMV).
So how can ADSP/DKIM be analogous you ask.
Actually I disputed it.
While it will be unusual to have multiple From header email-
addresses, having multiple DKIM signatures will not be. This
means a message may be expected to generate several additional
target-able transactions made by receiving hosts and MUAs who
evaluate DKIM message signing.
Nobody is required to check ADSP for a valid existing signature.
If you want "signature processing limits" put them in 4871bis.
otis-dkim-adsp draft requires one compared to SSP-03 draft's
of three discovery transactions.
SSP-03 does not yet reflect the outcome of two polls reducing
*two* to in essence *one* for existing or "mailable" domains.
John Levine's replacement for this also uses three.
Existing domain + plus practise is two, an optional "mailable"
check can take at most three queries replacing the NXDOMAIN
check. That is at most four queries, and folks can skip AAAA
if they judge it as irrelevant for their purposes.
IMHO, only the MX record should ever be checked or the
Internet will suffer.
Receivers will do what they want to determine "mailable", and
that is as it should be. They can also use RFC 4407 if they
don't grok "envelope sender" in RFC 346x, 3834, 4408, 2821bis,
and so on. Or if they like PRA better for a "visible in our
calendar outlook" effect.
RFC4406 (Sender-ID) made a point to include "v=spf1"
RFC 4408 makes the opposite point...
Microsoft
...under Godwin's law this thread is now dead ;-) Take care,
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html