Subject: [ietf-dkim] DKIM Working Group Summary, IETF 65

From: DKIM Chair <[email-masked]>
Date: Thu, 23 Mar 2006 10:30:01 -0500

This is a brief summary of what happened in the DKIM sessions at IETF
65.  Detailed minutes will follow to the DKIM mailing list when I can
get them cleaned up, probably early next week.

Note that the reply-to for this message has been set to the DKIM
mailing list, [email-masked]

----------------------------------------------
Discussion of issues for draft-ietf-dkim-threats; few issues left, open
issues covered, document should be ready for final version next week.

Discussion of issues for draft-ietf-dkim-base. Several were minor. Main
issues:
* Issue: mailing-list considerations. Long discussion started on the
mailing list, needs to be continued there.
* Issue: "r=" tag, specifying a "report-to" entity. Defer consideration
to SSP document, but then we considered whether to also have it in the
key record (or something reachable through the selector). Further
discussion to go to the mailing list.
* Issue: transition plan for new crypto algorithms, and specifically,
transition from SHA-1 to SHA-256 hashes. Some discussion here, but
discussion ultimately deferred to the general issue of multiple
signatures. Consensus among the security folks is to let the verifier
decide which crypto is "best".
* Issue: hashing the message separately and putting that hash into the
header, then hashing and signing the header. Room consensus for, will
take to the mailing list.
* Issue: some popular mail implementations do things that make header
canonicalization of "simple" problematic. Informative text will be
added to suggest what the signer should watch for when using "simple"
to sign.
* Lots of other minor issues, as noted above.

We briefly discussed splitting the base document (specifically to
remove references to retrieving DNS records, but there may be other
things that make sense to split out), and deferred some longer
discussion to the mailing list.

Jim Fenton introduced the signing policy/practices proposal and issues;
after the base document, we'll be attacking this in earnest. The name
is still in flux, with some thinking that "policy" is not the right
term, others thinking that "practices" isn't either. We were pointed to
some work called DDDS that's been introduced in the speermint working
group, which might help us with the work (not with the naming), so
we'll have a look at that.

Tony Hansen introduced the DKIM Overview document that he's gotten
Phillip and Dave to work on with him. The idea is that this document
contain informative text to explain history and decisions that it
doesn't make sense to put in the normative documents. There was
discussion of what should go in here: some would like to have all
informative text moved here, while others point out that implementors
often don't read auxiliary documents, and everything should stay in the
base doc. There's also the issue of how this dovetails with the DKIM
Best Practices document that the AntiSpam Research Group is planning to
do, and John Levine will work with Tony to sort that out.

Doug Otis presented his proposal about opaque IDs and signing roles. 

Tony briefly talked about a test message corpus that's available for
implementors to use to test their implementations.

--
Barry Leiba, DKIM co-chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

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

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Mar 2006 09:17:43 -0500

If there is going to be a SSP renaming consideration, may I suggest
"Profile" instead of Practice?

    Sender Signing Profile

Probably the acronym should change too, maybe:

    DSP      DOMAIN (or DKIM) Signature Profile
    MSP      Message Signature Profile
    DMSP     DKIM Message Signing Profile

This keeps the door open to exposing more information about the SIGNER and
not just SENDER.

I like Profile because that is more accurate to what a vendor might help
prepare for operators when setting up DKIM.  He is setting up a DKIM Message
Signing Profile.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Hector Santos" <[email-masked]>

> Practice?
> I would hope that everyone practices a safe DKIM Sender Signing Policy!
:-)
>
> Labeling it as a "Sender Signing Practice" doesn't sound right.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 24 Mar 2006 08:28:36 -0500

Would it make sense to break these up into separate threads?  Anyway, here
is my comments on some of these issues.

----- Original Message -----
From: "DKIM Chair" <[email-masked]>
To: <[email-masked]>

> discussion to go to the mailing list.

Personally, I like the idea of having a possible (by default) fixed
notification common name (user part), such as one of following names:

    DKIM-ABUSE  (My preference, since ABUSE is already required)
    DKIM-POSTMASTER
    DKIM-ADMIN
    DKIM-SYSOP

etc.

Dave Crocker's RFC 2142 can serve as a guide.

Just a small note about operation consideration:  The r= report address must
be legitimate and acceptable. If a DKIM verifier attempts to send a report,
it can learn very quickly if it is just a fraudulent address. So if not
acceptable, it can become a source for putting more weight on a bad message.
Some guidance should be provided for possible actions to take, i.e, stop
sending future reports.

> decide which crypto is "best".

I like the idea or the potential to offer high-value domains the ability to
secure their operations by doing one or more of the following:

 1) Assign domain owned user addresses for communications,

 2) Joint venture, collaborate, outsource with a ESP that
    has the DKIM security we are looking for, and assign the
    user a special ESP domain controlled address.

 3) During the user account sign-up we will automatically find
    out if the target domain offers the security we are looking
    for.

In my view, the idea that high-value domains will place their faith on
signing messages and then "cross their fingers" that it will be correctly be
supported seems me to be a little unrealistic.   This touches base with the

Practice?

I would hope that everyone practices a safe DKIM Sender Signing Policy! :-)

hmmmm, maybe it is obvious by now,  but it should be highlighted that there
seems to be two camps here in regards to SSP:

   - Those who think SSP is not necessary
   - Those who think SSP is vital to DKIM

I think it is required.  The specs has a natural presumption of a SSP
Neutral policy (Missing SSP key defaults to NEUTRAL, o=~, policy).   This is
very important. Even if a domain doesn't define a SSP key, he is telling the
world he is NEUTRAL. He doesn't care what happens to the message.

What I seek operationally, is that everyone follows SSP
verification/authorization whether one defines SSP record or not.  The
protection in DKIM comes when every piece of software is expected to
practice SAFE SSP.   So that if a DOMAIN says:

        "We don't send mail"
        "We never sign mail"
        "No 3rd party SHOULD ever sign our messages"

etc, etc, it is vitally important that the domain policy, definition,
"practice" or requirement, whatever we wish to call it, that we honor that
security.  I don't understand why we would want to ignore this fundamental
domain security?

So whatever we want to call it, to me, it a small moot point over what how
we expect to use it.   If it isn't require to be honored than what's the
point?

That said, I think ideas like DDDS and similar concepts is a step in the
right direction.  SSP will offer ways to resolve so many issues of
"expectation" in a highly chaotic world of mail transactions.  So whether
its DDDS, SSP or what I call TMS (Transaction Management System), domains
can learn more about who they are sending data to, as well as domains can
learn about those they are receiving mail from.

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 24 Mar 2006 11:51:09 -0600

> "Profile" instead of Practice?

Another possibility is "Preferences" maybe?

-- 
Arvel

---

From: Jim Fenton <[email-masked]>
Date: Fri, 24 Mar 2006 14:14:05 -0800

> Another possibility is "Preferences" maybe?
I'd prefer a word that is descriptive of what the signer does, rather
than making a request of the recipient.

-Jim

---

From: Barry Leiba <[email-masked]>
Date: Sat, 25 Mar 2006 01:58:38 -0500

> Would it make sense to break these up into separate threads?  Anyway,
> here is my comments on some of these issues.

It might, but mostly it would be useful to remove
  [email-masked]
  [email-masked]
  [email-masked]
from the distribution list if there are further replies to this thread.
Those addresses were only there for the official Security Area
submission of the WG meeting summary.

Barry

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 25 Mar 2006 03:35:56 -0500

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: <[email-masked]>

>>> Hector wrote:
>>> If there is going to be a SSP renaming consideration, may 
>>> I suggest "Profile" instead of Practice?

>> Arvel wrote:

> than making a request of the recipient.

I don't understand the last part of this sentence? Can you elaborate?

How about?

     DSD  - Domain Signature Description
     MSD  - Message Signature Descriptor

---

From: Jim Fenton <[email-masked]>
Date: Sat, 25 Mar 2006 23:32:33 -0800

> I don't understand the last part of this sentence? Can you elaborate?
Sorry; I reread my comment and it was rather terse.

I don't pretend to understand all of the issues (particularly the legal
ones in some jurisdictions) but there is apparently concern in some
places about policies that suggest that some messages (even spoofed
ones) not be delivered.  For that reason, I have been favoring terms
that are descriptive of what the originator's domain does rather than
terms that suggest some action on the part of the verifier.  I think
"Preferences" is in the latter category.

Hope this is clearer.

-Jim

---

From: Arvel Hathcock <[email-masked]>
Date: Sun, 26 Mar 2006 11:56:58 -0600

> than making a request of the recipient.

Ah, yes, good point.

-- 
Arvel