[ietf-dkim] DKIM Working Group Summary, IETF 65
DKIM Chair <leiba@watson.ibm.com> Thu, 23 March 2006 15:34 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRpT-0008Ov-CB for ietf-dkim-archive@lists.ietf.org; Thu, 23 Mar 2006 10:34:27 -0500
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRpR-0008JD-Tp for ietf-dkim-archive@lists.ietf.org; Thu, 23 Mar 2006 10:34:27 -0500
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2NFVUja006288; Thu, 23 Mar 2006 07:31:30 -0800
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k2NFVHOf006269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Thu, 23 Mar 2006 07:31:18 -0800
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k2NFUtMD032534; Thu, 23 Mar 2006 10:30:55 -0500
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k2NFUc0193876; Thu, 23 Mar 2006 10:30:38 -0500
Received: from saturn.watson.ibm.com ([9.12.235.27]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k2NFUbj209784; Thu, 23 Mar 2006 10:30:37 -0500
Date: Thu, 23 Mar 2006 10:30:01 -0500
From: DKIM Chair <leiba@watson.ibm.com>
To: ietf-dkim@mipassoc.org
Message-ID: <9FDEAD9885C9F556FFA13FF5@saturn.watson.ibm.com>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Songbird: Clean, Clean
Cc: saag@mit.edu, dkim-ads@tools.ietf.org, dkim-chairs@tools.ietf.org
Subject: [ietf-dkim] DKIM Working Group Summary, IETF 65
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
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@mipassoc.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@watson.ibm.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
- [ietf-dkim] DKIM Working Group Summary, IETF 65 DKIM Chair
- [ietf-dkim] SSP - Sender Signing [Policy | Practi… Hector Santos
- Re: [ietf-dkim] DKIM Working Group Summary, IETF … Hector Santos
- Re: [ietf-dkim] SSP - Sender Signing [Policy | Pr… Arvel Hathcock
- Re: [ietf-dkim] SSP - Sender Signing [Policy | Pr… Jim Fenton
- Re: [ietf-dkim] DKIM Working Group Summary, IETF … Barry Leiba
- Re: [ietf-dkim] SSP - Sender Signing [Policy | Pr… Hector Santos
- Re: [ietf-dkim] SSP - Sender Signing [Policy | Pr… Jim Fenton
- Re: [ietf-dkim] SSP - Sender Signing [Policy | Pr… Arvel Hathcock