Review of draft-ietf-dkim-ssp-08

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

 



$Id: draft-ietf-dkim-ssp-08-rev.txt,v 1.1 2009/01/02 19:05:45 ekr Exp $

This document describes a way for domains to publish their policy
vis-a-vis signing emails with DKIM. The idea here is that when
you receive an email that is not signed you would like to be able
to distinguish (at least) two cases:

- The domain doesn't sign.
- This is a forgery.

This document (hereafter called ADSP) allows the domain to advertise
its signing policy, thus allowing recipients to distinguish these
(and some other) cases.

Generally, this approach and the protocol it describes seem sound.
However, I have some concerns as detailed below.

One general question: I see you're using TXT here. I know this
is a hot button for the DNS people. If you haven't cleared this
with them, that might be good. If you have, then ignore this
comment.



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.
I.e., I want to forge a message apparently from example.com, which
has "dkim-all". I generate a message with "From: ekr@xxxxxxxxxxx, ekr@xxxxxxxxxxx"
where I control example.org. I then serve a record for example.org 
indicating that I don't sign. If this is accepted, that seems 
potentially problematic.


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"? I mean, I could
just ignore the issue and do exact match. Would that constitute
"deciding"? What would not "deciding"?

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.

In addition, to the extent to which the point of security
considerations is to give the reader an accurate picture of the
security of the system, I don't think this works that well, as due to
the very low deployment of DNSSEC, in practice these records are
easily forged.



EDITORIAL
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 and so it needs
to be treated as unsigned, and that's where ADSP kicks in. But I
may have misunderstood, so some clarity here might help.


S 3.1.
   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?


-Ekr
_______________________________________________

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]