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, ietf-dkim(_at_)mipassoc(_dot_)org
----------------------------------------------
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 (leiba(_at_)watson(_dot_)ibm(_dot_)com)
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