Re: Review of draft-ietf-dkim-ssp-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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.

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@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.

Regards,
John Levine, johnl@xxxxxxxxx, Taughannock Networks, Cambridge UK
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]