This document (hereafter called ADSP) allows the domain to advertise
its signing policy, thus allowing recipients to distinguish these
(and some other) cases.
ADSP is a very, very narow design, that attempts to deal with only a
single threat: exact forgery of an address on the From: line. There's a
lot of other threats, arguably more important to address, but ADSP doesn't
deal with them.
One general question: I see you're using TXT here. I know this
is a hot button for the DNS people.
ADSP records are in the same _domainkey subtree as DKIM TXT records, so
they should be as OK.
TECHNICAL
S 3.
Hosts can look up the ADSP information of the domain(s) specified by
the Author Address(es) as described in Section 4.3. If a message has
multiple Author Addresses the ADSP lookups SHOULD be performed
independently on each address. This document does not address the
process a host might use to combine the lookup results.
I'd like to see some security analysis of why this is OK. Naively,
it seems like one might be able to get around ADSP using this feature.
Since we don't have any real experience with signed mail with multi
address From: lines, any analysis would just be a guess, and not a very
well informed one at that, so we figured it was better not to. Consider
these From: lines:
From: security(_at_)paypal(_dot_)com, crook(_at_)phishpharm(_dot_)biz ; ADSP
fail, pass
From: security(_at_)paypalsecurity(_dot_)com, crook(_at_)phishpharm(_dot_)biz ;
ADSP unknown, pass
From: friend(_at_)knowndomain(_dot_)com, someone(_at_)somewhere(_dot_)com; ADSP
pass, unknown
The first and second cases are probably bad guys, but the third could be
someone you know and trust and his friend who you don't happen to know
yet.
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.
S 4.3.
Check Domain Scope: An ADSP checker implementation MUST determine
whether a given Author Domain is within scope for ADSP. Given the
background in Section 3.1 the checker MUST decide which degree of
approximation is acceptable. The checker MUST return an
appropriate error result for Author Domains that are outside the
scope of ADSP.
I don't really undersand how the second (and maybe third) MUSTs are
operationalizable. How would I not "decide"?
You're right, the second isn't really anything you can do. The third says
that if, e.g., the domain doesn't exist at all, it has to return an error.
S 6.2.
An attacker might attack the DNS infrastructure in an attempt to
impersonate ADSP records to influence a receiver's decision on how it
will handle mail. However, such an attacker is more likely to attack
at a higher level, e.g., redirecting A or MX record lookups in order
to capture traffic that was legitimately intended for the target
domain. These DNS security issues are addressed by DNSSEC [RFC4033].
I don't understand why an attacker is more likely to redirect A or MX.
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?
S 2.7.
For example, if a message has a Valid Signature, with the DKIM-
Signature field containing "i=a(_at_)domain(_dot_)example", then
domain.example
is asserting that it takes responsibility for the message. If the
message's From: field contains the address "b(_at_)domain(_dot_)example" and
an
ADSP query produces a "dkim=all" or "dkim=discardable" result, that
would mean that the message does not have a valid Author Signature.
Even though the message is signed by the same domain, it fails to
satisfy ADSP.
I think this example might benefit from a bit more explanation.
As I understand it, this signature is invalid per DKIM
It's valid DKIM, but ADSP has additional semantics that are incompatible
with common auditing usage of the DKIM i= field. The -09 draft will have
a note pointing this out with a workaround. For an example of usage of
i=, see the DKIM signature on this message.
Note: The results from DNS queries that are intended to validate a
domain name unavoidably approximate the set of Author Domains that
can appear in legitimate email. For example, a DNS A record could
belong to a device that does not even have an email
implementation. It is up to the checker to decide what degree of
approximation is acceptable.
I don't really understand this graf. Can you rephrase?
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.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Cambridge UK
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf