[ietf-dkim] Draft DKIM minutes from IETF65

[DKIM Chair <[e-mail]>]

---------------------------------------------------------
The first DKIM working group session was on Monday, 20 March 2006, from
1300 to 1500 CST, in the Cortez C/D room.

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 lists.  This topic was too long to address in the
meeting, and discussion will continue on the mailing list.

* 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.  There's also the issue that there is insufficient
experience with SHA-256 to be sure about its robustness relative to
SHA-1.  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.  In the 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.

A handful of base issues were spilled over into the second session.

The second DKIM working group session was on Wednesday, 22 March 2006,
from 1510 to 1610 CST, in the Cortez C/D room.

We started the second DKIM session by finishing the review of the
base-spec issues with the few we hadn't gotten to on Monday.  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 then 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).

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.
There was only a little discussion because time was tight.  There were
comments that this would require a lot of DNS querying, and that it
might be more interesting theoretically than practically. 

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


Barry Leiba, DKIM Working Group co-chair  ([e-mail])
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