On Aug 2, 2006, at 4:35 AM, Stephen Farrell wrote:
Can you explain why they are, without recourse to any acronyms and
in a sentence or two each?
For the most part, Problem 1 together with Solution A is currently
being discussed, but this should not be seen as a forgone
conclusion. Solution A is generally related to an effort aimed at
preventing spoofing by blocking messages. The downside of this
approach is that mailing lists and related services will no longer
function. This might be a reasonable solution for transactional
messages related to commerce, but this would not be a reasonable
solution for general use. Such a (mis)application of policy would
likely cause support related havoc. Ignoring the disruptive aspect,
the Threat draft also indicates Solution A has serious weaknesses.
The disruption and these weaknesses are resolved by Solution B however.
As Solution B mentions, there is a more effective and less disruptive
approach where policy information is also less frequently accessed.
The requisite information for Solution B would be a list of
designated signing domains. This list overlaps much of the same
information provided for Solution A. Problem 2, which is both a
common ploy and a serious problem, is not resolved by Solution A
which is also why Problem 2 may seem out of scope. The difference in
the information presented to Solution A from that of Solution B is
likely just a flag indicating an exclusive (disruptive) use of the
designated signing domains. Solution B however resolves Problem 2 by
using virtually the same information as required for Solution A.
Solution B at first glance may seem to not require any policy
information. A designated signing domain list indicating which
domains are considered authoritative for the rfc2822 From header
identity allows smaller outfits an ability to leverage providers
offering DKIM services signed under a common domain. These DKIM
providers should require users to both authenticate and demonstrate
their reception of messages sent to email addresses they wish to
use. This would be little different than the techniques used to
subscribe to a mailing list. As indicated in the SAT definition, the
tuple is qualified as being a member of a designated signing domain
for the rfc2822 From header identity. The infrequent need to qualify
the tuple being retained and later used to annotate messages would be
when this policy information is acquired. This approach also does
not require _any_ searching for policy and will _not_ disrupt email
delivery. Solution B will also be effective at resolving both
Problem 1 and 2, whereas Solution A is not effective.
The remaining problems and solutions assume policy can be expressed
by different records for different purposes.
Problem 3 is also a serious problem and is responsible for much, if
not most, of the abusive email. With DKIM's slightly higher
overhead, concurrently curtailing some of this abusive traffic should
help ensure DKIM introduction provides a positive experience.
Solution D parallels a similar solution previously tried by a prior
WG. As the drawback for this approach indicates, the related policy
information would be immensely difficult to manage.
Solution E however offers an approach that should be very easy to
manage. Even with this being easy, it is difficult to convince
administrators of a need for this change. Solution E announces the
use of DKIM at the EHLO and indicates there is an assured method to
authenticate the client beforehand. When making modifications in DNS
for keys and policy, introducing this change as a policy should also
prove effective at quelling Problem 3. To help promote this
approach, a flag is the DKIM sender's policy might also indicate that
this client method of authentication MUST be used by "this" domain.
Until Problem 4 actually becomes a problem, there is likely little
desire to work through the details or consider other related
solutions. Solution F would also be difficult to manage. Perhaps
Solution E will prove effective and these issues will never warrant
further consideration. : )
Problem 5 was raise by Tony. It seems that it should be covered by a
review.
Problem 6 is a real problem where I suspect unexpected application of
policy may occur. Although perhaps a rat-hole, some advice might be
included in the draft regarding attempts a Solution H.
This was a review, where Solutions A, C, D, F, G, and H are not be
recommended. There should be greater focus on Problems 1, 2, and 3,
and Solutions B and E.
-Doug
Douglas Otis wrote:
This explores a range of possible policy and auxiliary records and
label scenarios as a general exercise. Rather than repeating the
same phase fairly often, acronyms are still used, but now are
defined up front. The expected drawbacks are retained to help
with their eventual disposition.
Definitions of Terms
--------------------
Resource Record (RR): The storage element selected by type used by
DNS containing structured content.
Resource Record Set (RRset): One or more Resource Records at a
specific domain name.
Originator Address (OA): An email address found within the
2822.From header field.
Originator Address Domain (OAD): The domain of an OA.
Current Address (CA): The latest dominant email-address introduced
per RFC2822. (The latest 2822.Resent-Sender, Resent-From, Sender,
or From.)
Current Address Domain (CAD): The domain of an CA.
Mail From Domain (MFD): This represents the domain within the
2821.Mail_From parameter.
Signing Domain (SD): The domain verified by a valid signature
located by DKIM-Signature header field 'd=' parameter.
Policy Publishing Domain (PPD): The domain from where policy is
published, excluding any special prefix for referencing the policy
RR.
Designated Signing Domain (DSD): A domain contained within policy
providing authoritative signatures for the PPD.
Non-Designated Domain (NDD): A domain not contained within policy
and not considered authoritative for the PPD.
Designated Host-Name (DHN): A host-name designated as being
authoritative for the PPD.
Direct Message (DMSG): A message issued and signed by the OAD.
Indirect Message (IMSG): A message issued on behalf of the OA and
signed by a NDD.
Signature/Address Tuple (SAT): The OA combined with either a
valid signature by a DSD or a DMSG.
--------------------
=========
Problem 1: Spoofs of the OA in phishing attempts.
Solution A:
In the case of IMSGs, OAD policy might provide a means to block
spoofs of DMSGs. Acceptance could be denied when OAD policy
indicates exclusive use of DSDs, and the SD is not in conformance.
Drawback of solution A:
a) A recipient can not differentiate DMSGs from IMSGs. Exclusive
use of DSDs will not conform to common IMSG related services, such
as mailing-lists or e-invites. Policy may be ignored (see
Solution B), the message may be annotated to indicate a level of
policy assertion conformance, or the message may be refused when
not conforming with policy assertions.
b) The OA may not be visually apparent or may be visually
misleading. When just display-names are visible, or look-alike or
international domains are used, the recipient may be unable to
discern the exact OA being displayed.
-----
Solution B:
Track SATs at the MUA with an address book or correspondence log,
and then annotate messages matching an SAT. This does not require
policy be obtained to prevent spoofing and this also resolves look-
alike issues.
Drawback of solution B:
This introduces a new requirement for MUAs to annotate messages
based upon SATs, where this information should also be exchanged
between disparate MUAs for the same user.
=========
Problem 2: Spoofs of visual content where the OA may also be
contrived to be visually misleading in phishing attempts.
Solution C:
When a domain can be ascertained from the visual content of a
message, this domain can be checked for DSD conformance with OAD
policy at this domain. Acceptance could be denied when OAD policy
indicates exclusive use of DSDs, and the SD is not in conformance
with this policy.
Drawback of solution C:
There is no reliable proactive means to identify cognitively
similar message content when ascertaining the domain. Being a
niche problem, this would not likely have a specific policy
expressed, and the lack of conformance with OAD policy may be
prone to false positives.
-----
See Solution B.
=========
Problem 3: SMTP host-name are utilized within administrative
domains by compromised systems for sending abusive messages, both
signed and unsigned.
Solution D:
Authenticate the reverse DNS host-name or EHLO and then reference
a host-name policy providing DSDs where the left-most host-name
label is not used for the reference. A valid DKIM signature by a
DSD then validates the administrative' control of the message's
introduction and demonstrates conformance with the policy.
Drawback of Solution D:
There can be an immense number of DSDs associated with an SMTP
client host-name. While there are techniques to efficiently
resolve a large name:name relationship using DNS (query of
<signing-domain>._policy-label.<publish-domain>), the maintenance
of these relationships by an administrative domain may be daunting.
-----
Solution E:
Require that a DKIM sanctioned method be used to authenticate SMTP
client host-names. For example an Address RR must found at
_dkim.<host-name> that validates the client. The EHLO could also
encompass the _dkim.<hostname> to avoid replicate A records, and
to signal use of dkim at the EHLO.
Drawback of Solution E:
This would only protect systems that never send email and thus
would not have an assigned _dkim specific IP address. However, a
compromised system implementing DKIM signing seems unlikely
protected by supplemental policies or records. This protection
would require some means to assert that host-names must provide
SDs within the same domain, and hope that the private key was not
also obtained.
=========
Problem 4: Replayed messages and bogus signatures are difficult to
detect and effectively triage.
Solution F:
Publish a policy that returns DHNs at SDs. After verifying the
host-name, and finding a DHN association at the SD, invalid
signature at a DHN can be considered bogus, and valid signatures
at a DHN should not be considered the product of replay.
Drawback of solution F:
These relationships of possibly disparate administrative domains
may be daunting. These policies would not offer a basis to refuse
a message when a DHN is not established.
=========
Problem 5: Spoofing of the CA, when the CA is not also the OA.
Solution G:
When the CAD is not within the SD, reference a specific CAD policy
for DSDs and check for conformance.
Drawback of Solution G:
This may lead to additional loading of the DNS server when some
verifiers attempt to validate additional header fields within the
message. As this field is not likely to be the target of a spoof,
the added overhead may be considered unwarranted.
=========
Problem 6: Spoofing of the MFD.
See Solution F, except replace SD with MFD.
-----
Solution H:
Attempt to impose the OAD policy upon the MFD, in lieu of a policy
specifically for the MFD. This may short-cut some checks and
prevent some possible handling delays.
Drawback of solution H:
Can only be used to bypass some checks. Lack of an DSD
association corresponding to the MFD can not be acted upon for
refusing messages.
-----
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
