Subject: [ietf-dkim] Comments on draft-ietf-dkim-deployment-07

From: SM <[email-masked]>
Date: Sun, 19 Jul 2009 01:22:29 -0700

Hello,

I have the following comments about 
draft-ietf-dkim-deployment-07.  The document is for people involved 
in development, deployment and operations.  These are different 
audiences.  Some of the material in this document is at a high level 
and might be a challenge for people involved in deployment and 
operations.  I'm not suggesting any change to that.

In Section 2.3, it is mentioned that a DKIM signing entity can serve 
different roles, such as author of content, versus operator of the 
mail service, versus operator of a reputation service.  I don't 
understand the use of the word role in the content of a reputation 
service.  From the examples, it sounds more like an input instead of a role.

   "For those originating message content, the most likely choice of sub-
    domain naming scheme will by based upon type of content
    ...
    where the choices are best dictated by whether they provide the
    Identity Assessor with the ability to discriminate usefully among
    streams of mail that demonstrate significantly different degrees of
    recipient acceptance or safety."

I noticed that some sub-domain schemes are used as an "opaque identifier".

   "For those operating messaging services on behalf of a variety of
    customers, an obvious scheme to use has a different sub-domain label
    for each customer.  For example:

                           widgetco.example.net"

I am not in favor of such a scheme as it is vendor-oriented.  If the 
customer changes their messaging service, their signing identify is 
no longer valid.  One of the advantages of DKIM is that it doesn't 
rely on the originating IP address, i.e. the service or content is 
not tied to IP addresses.  We would be taking a short term approach 
by encouraging a tie-in with the transmitter of the message.

I'm going to use this mailing list as an example.  The message is 
sent through songbird.com.  I don't know the relationship between 
mipassoc.org and songbird.com.  I know that the mailing list is 
associated with the mipassoc.org domain.  As the receiver, it's 
easier for me if the DKIM signer is mipassoc.org.  If we were to use 
the obvious scheme, then the DKIM signer would be 
mipassoc.org.songbird.com or something similar.  If the mailing list 
is moved to att.com, the DKIM signer would be 
mipassoc.org.att.com.  The change in signing identity is not to the 
advantage of the sender or the receivers.

Section 2.5 focuses on variations in Organizational Trust versus 
Message Risk.  Adopting an Accept and Contact approach without any 
filtering is troublesome for messages from some types of 
senders.  This is my opinion and not a suggestion to change that section.

In Section 6.2, is the "i=marketing.domain.example" correct?

Section 6.3 is about third party signatures.  ESPs and ISPs are in 
the same paragraph.  In my opinion, they are different as they have 
different orientations.  What they have in common is the aggregation 
of mail traffic which means that you will see "good" mail and "bad" 
mail.  The level of bad mail from an ISP varies according to the 
"quality" of its users at any given point.  There is some good advice 
in this document which might help.  Third party signatures from ESPs 
are not that useful when the ESPs aggregate their mail traffic.  This 
is not a rule.  There are mechanisms outside the scope of DKIM where 
the information may be of use.

I'm not too keen about the paragraph about Forwarders as it mixes 
forwarding mail with mailing list.  There are two types of 
traffic.  The second one generally "breaks" DKIM signatures.

Senders which would like to prevent phishing might want to avoid 
third party signatures.  There are valid cases when third party 
signatures are useful, e.g. forwarders, etc.

In Section 7.3.3:

   "An organization (Company A) may specify its signing practices by
    publishing an ADSP record with "dkim=all" or "dkim=discardable".  In
    order to avoid misdelivery of its mail at receivers that are
    validating ADSP Company A MUST first have done an exhaustive
    analysis to determine all sources of outbound mail from its domain
    (companyA.example) and ensure that they all have valid author
    signatures from that domain."

I do not understand what the authors mean by "misdelivery".  From the 
example, an ADSP of "discardable" means that the email can be 
discarded.  That isn't a wrong delivery as the receiver accepted 
delivery of the message.

In Section 7.4:

   "An organization may choose to outsource certain key services to an
    independent company"

Third-party is more appropriate than "independent company".

BTW, RFC 989, RFC 1991 and RFC 3164 are obsolete.

Regards,
-sm

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 19 Jul 2009 16:19:42 -0700

> service.  From the examples, it sounds more like an input instead of a role.

A proactive reputation service vouches for the sender.  The sender could 
collaborate with the reputation service, to affix signature by that
reputation service to the message; this is a means of imparting the reputation 
service's own reputation to the sender.  Hence, the reputation service is 
performing a proactive role for that sender.  (By way of example, this is what 
Goodmail does, which perhaps explains why I might think of this scenario...)

> I noticed that some sub-domain schemes are used as an "opaque identifier".

Only some?

> no longer valid.  One of the advantages of DKIM is that it doesn't 

What you or I or anyone in the working group is in favor isn't the issue.  The 
issue is what a signer and an assessor might find useful.  The paper suggests 
some schemes that are likely to have assessment utility.

Choices for labels to use, for distinguishing different message streams will 
have tradeoffs.  Any particular choice will have negatives as well as positives. 
  In this example, the premise was that the service provider's domain name was 
being used, rather than the customer's.  Sometimes that choice makes sense or is 
the only one that is available.

The purpose of the paper is not to dictate normative behavior -- note that it
intends 'informational' status; it is to explain how things work and what sorts
of choices can be available.

If you feel that tradeoffs are inadequately explicated  -- and I mean tradeoffs,
rather than preferences -- please do supply some additional text.

> senders.  This is my opinion and not a suggestion to change that section.

What language are you suggesting to change, and in what way?

> In Section 6.2, is the "i=marketing.domain.example" correct?

yes.

If your concern is the use of .example as a TLD: 
http://www.rfc-editor.org/rfc/rfc2606.txt

If you have some other concern, what is it?

> the information may be of use.

You appear to be commenting on the efficacy of particular choices, but that's 
not the purpose of this document.  It is trying to explain the choices, in terms 
of DKIM use, not assert recommendations.

> traffic.  The second one generally "breaks" DKIM signatures.

A variety of processes can break them.

I guess the challenge is in finding a single term to cover them.  RFC 5598 
doesn't quite permit calling them all "mediators".  Forwarding is pretty generic.

> third party signatures. 

Oh boy.  That's a topic I hope the documented is not required to touch.

> discarded.  That isn't a wrong delivery as the receiver accepted 

What the receiver does with the message can be delivery as intended by the 
sender or it can be delivery elsewhere, such as a junk folder.  From an 
end-to-end standpoint, that's effectively misdelivery.

> Third-party is more appropriate than "independent company".

Well, "third-party" is a term of art in the DKIM realm and it means something 
potentially different than meant here.

> BTW, RFC 989, RFC 1991 and RFC 3164 are obsolete.

So? This isn't normative use.  And they are not irrelevant.

(On the other hand, 3164 appears to be an unused citation.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John Levine <[email-masked]>
Date: 20 Jul 2009 12:05:28 -0000

>> Senders which would like to prevent phishing might want to avoid 

Only if they deeply fail to understand what DKIM does.  I agree this
has no place in a deployment document.

R's,
John