Subject: [ietf-dkim] [Fwd: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)]

From: Jim Fenton <[email-masked]>
Date: Fri, 14 Aug 2009 10:01:46 -0700

I haven't seen this announcement here, probably because
[email-masked] doesn't subscribe to this list.

-------- Original Message --------
Subject: RFC 5617 on DomainKeys Identified Mail (DKIM) Author Domain
Signing	Practices (ADSP)
Date: Wed, 12 Aug 2009 16:53:22 -0700 (PDT)
From: [email-masked]
To: [email-masked], [email-masked]
CC: [email-masked], [email-masked]
Newsgroups: gmane.ietf.announce,gmane.ietf.dkim

A new Request for Comments is now available in online RFC libraries.

        RFC 5617

        Title:      DomainKeys Identified Mail (DKIM) Author
                    Domain Signing Practices (ADSP)
        Author:     E. Allman, J. Fenton,
                    M. Delany, J. Levine
        Status:     Standards Track
        Date:       August 2009
        Mailbox:    [email-masked],
                    [email-masked],
                    [email-masked],
                    [email-masked]
        Pages:      21
        Characters: 43093
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-dkim-ssp-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5617.txt

DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the
source and contents of messages.  This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address.  It defines a
record that can advertise whether a domain signs its outgoing mail as
well as how other hosts can access that record.  [STANDARDS TRACK]

This document is a product of the Domain Keys Identified Mail Working
Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

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

---

From: hector <[email-masked]>
Date: Sat, 15 Aug 2009 07:32:54 -0400

Congratulations on getting this published.  Hopefully, it will taken 
serious by many domains to help provide a reasonable return on DKIM 
processing. In lieu of a standardized (and public) reputation system, 
network, ADSP can give some value.

I have a few questions seeking clarification, confirmation mostly, 
because if I'm going to begin to implement DKIM with an ADSP focus for 
our customers, we will need to be able translate the information in 
the spec into easy to understand documented and online "Help" for 
customers.

1) With the policies:

    dkim=all vs dkim=discardable

In layman terms, one is actionable (discardable) and one is not (all). 
One is an "Error" resulting in a reject, one is a "Warning" not 
resulting in a reject, in both cases, can be logged/recorded?  Our GUI 
setup may show it like so for example:

   Author Domain: domain.example

   DKIM Signing Policy:

   (o) unknown     - your mail may be signed

   (_) all         - Your mail are always sign, however
                     verifiers SHOULD NOT reject invalid signatures.

   (_) discardable - Your mail are always sign, and
                     verifiers MUST reject invalid signatures.

   [ PUBLISH ] [CANCEL ]

Is that the basic translation and fair way to put it?

2) DKIM=UNKNOWN

Is there any actionable logic for optional signing?

I mean, you may not always sign, but if you do, it must not be invalid?

I just want to make sure in our help/doc to indicate whether 
publishing with unknown is the same as no ADSP record. One is 
explicit, the other is implicit.  I may not always sign, but if I do, 
take it serious.  Having no records could be viewed you don't care 
either way.

I guess as it seems to be now, it would be a "Warning" but still 
acceptable (no rejection on this basis).  But see the tail end of 3.

3) Finally 3rd party signatures.

Please believe me I don't wish to rehash this. It was the one thing 
that I really felt will help domains.  Not so much in defining the 
difficult task for valid use cases for the inclusion of 3rd signature 
policies, but rather the exclusion of 3rd parties.  For example, 
appendix B.4 says:

B.4.  Third-Party Senders

    Another common use case is for a third party to enter into an
    agreement whereby that third party will send bulk or other mail on
    behalf of a designated Author or Author Domain, using that domain
    in the [RFC5322] From: or other headers.  Due to the many and
    varied complexities of such agreements, third-party signing is not
    addressed in this specification.

Ok, I accept this, we had hard time defining 3rd party situations. 
But this is not the same as the one hard logical conclusion a domain
may have:  He doesn't do 3rd party signatures nor expect it.

So it seems me that the explicit declaration of a ADSP policy, the 
only options provided to prevent it are the explicit DKIM=ALL and 
DKIM=DISCARDABLE declarations.

However, does the explicit DKIM=UNKNOWN declaration also imply 
exclusive Author Domain Signing?  An explicit DKIM=UNKNOWN should 
suggest ADSP operations only, even if the signature is optional.

Is that a correct or incorrect consideration?

Thanks

---

---

From: Jim Fenton <[email-masked]>
Date: Tue, 18 Aug 2009 14:36:04 -0700

Hector,

Here are my interpretations.  Everyone, please bear in mind that these
are just that and others are free to disagree.  I'm not interested in
getting into a debate about this.

It's not clear to me that this is really a standardization discussion at
this point, so perhaps we should take discussions of this sort to
another list such as [email-masked].

Comments inline...

> Is that the basic translation and fair way to put it?

I disagree that "all" is not actionable.  There are several things the
verifier/assessor can do.  (1) Apply more stringent content checking
(perhaps changing the threshold values or something).  (2) If the GUI is
under the control of the assessor (such as a webmail client), display a
visual warning.  If not, do something like add [dkim unverified] to the
subject line.  Some of you may have seen that if I responded hastily to
a message without cleaning that up, because I have been trying that out
for quite some time now.

> acceptable (no rejection on this basis).  But see the tail end of 3.

I would advise against treating a signature that is invalid any
differently from a signature that isn't present.  There are intermediate
agents that might break the signature, and we don't want to give the
impression that applying a signature might increase the risk of
non-delivery.  Furthermore, dkim=unknown has the same meaning as the
lack of an ADSP record.

> Ok, I accept this, we had hard time defining 3rd party situations. But
> this is not the same as the one hard logical conclusion a domain

dkim=unknown doesn't imply that there is any Author Domain Signing going
on, and it is always (regardless of the ADSP value) OK for an
intermediary to apply a DKIM signature if it's willing to take
responsibility.  So ADSP is completely silent on the presence or absence
of third-party signatures.

Again, dkim=unknown has exactly the same semantics as the lack of an
ADSP record.  A published ADSP record will normally have a longer
time-to-live than the negative caching of the lack of one, so publishing
a record will cut down on DNS traffic.

My answer is that this is an incorrect consideration.

Hope this helps.

-Jim

---

From: hector <[email-masked]>
Date: Wed, 19 Aug 2009 01:59:05 -0400

> another list such as [email-masked].

Perhaps.  Not interesting in extending this beyond other than a 
thought.  If others want to initiate an ERRATA, I am not asking for it.

I think it is unclear of the purpose of having DKIM=UNKNOWN if its not 
for optional but exclusive Author Domain (AD) signing.  I hear what 
you said.  But ADSP is about exclusive AD signing. No?

     OPTIONAL
     ALWAYS
     ALWAYS+DISCARD IF INVALID

is pretty much how I read it and how I was thinking of it having it 
documented for people.

Not having a ADSP should be the only thing that says you are not an 
ADSP participant.  The people JL says will never publish it.

But having one, even as an UNKNOWN should suggest something other than 
non-ADSP participation.

JMO

---