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@xxxxxxxxxx, crook@xxxxxxxxxxxxxx ; ADSP fail, pass > > From: security@xxxxxxxxxxxxxxxxxx, crook@xxxxxxxxxxxxxx ; ADSP unknown, pass > > From: friend@xxxxxxxxxxxxxxx, someone@xxxxxxxxxxxxx; 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@xxxxxxxxxxxxxx", then domain.example > > is asserting that it takes responsibility for the message. If the > > message's From: field contains the address "b@xxxxxxxxxxxxxx" 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf