At Fri, 2 Jan 2009 19:22:25 -0500 (EST),
John R Levine wrote:
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.
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.
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, 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).
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?
Because the legitimate URL the user is dereferencing uses TLS?
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.
I would suggest that some explanation like this should go in the document.
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf