We don't see any way to tell these apart without consulting external
reputation databases, which are way outside the scope of ADSP and DKIM.
OK, but I don't see how it helps to put the job of making this
judgement on the implementor, who probably has less expertise
and time to think about this than the DKIM WG has
Honest, we thought about it and have no advice to give. Different
mail users will have different tradeoffs between losing real mail and
accepting bogus mail, and we really have no experience at all with
signed mail with multi-address From: other than contrived examples.
especially as there is at least one policy that more or less
obviates ADSP (treat all addresses as having the weakest policy
advertised by any of them).
That's certainly one policy you might use if your tradeoff avoids
losing real mail.
These are different attacks with different objectives. If I'm doing
phishing, then forgery seems more useful to the attacker.
Why phish if you can hijack the real traffic to the target?
Because the legitimate URL the user is dereferencing uses TLS?
True, although we were thinking of mail. Again, lacking any experience
at all here we're just guessing.
Many people have pointed out that in practice you can trivially circumvent
ADSP by using lookalike domains, e.g. paypalsecurity.com or
www.paypal.com. One way to address this would be to check to see if the
domain is in use at all for e-mail, since the number of domains in use for
mail is a tiny fraction of all of the names in the DNS. Unfortunately,
due to the ancient SMTP rule that use an A record, and now also AAAA, for
fallback if a domain has no MX record, any name with an A or AAAA record
can potentially be used for mail. There's a range of more or less
aggressive heuristics to see if a name with an A/AAAA record really is
used for mail (e.g., try to connect to port 25 and see if you get a hard
rejection), but there's no agreement on which if any an ADSP client should
use.
I would suggest that some explanation like this should go in the document.
My recollection is that there was less consensus than one might hope on
that particular explanation.
R's,
John
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf