THESE ARE PRELIMINARY DRAFT MINUTES. They should not be considered final and official at this time, until they are confirmed on the DKIM Mailing List . -------------------------------------------------------------------- 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. A complete issues summary appears below. The main issues were: * 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 a set of proposals, including: * Key group tags -- minimize the use of sub-domains, retain trust for a subset of the domain, aggregate key-related records. * Opaque ID -- coupled with a key revocation scheme, opaque-ID offers an alternative to per-user key revocation. * EHLO association -- associating EHLO with the DKIM signing domain using PTR RRset conventions can allow message acceptance without risk of replay abuse. * Signature roles -- can indicate the source and exclusivity for local trust maintenance. There were comments that opaque-ID revocation would require a lot of DNS querying, and that the meta-information might violate layering. There was also a sense that some of these proposals would need more discussion to determine whether they are practical. There was only a little discussion in the meeting because time was tight. Tony briefly talked about a test message corpus that's available for implementors to use to test their implementations. Tony is updating the corpus, and asks for feedback on some of the directions he's taking it. --------------- Issues summary --------------- Threats issues: 1171: Clarification of the DKIM mechanism in introduction Close, use current text 1172: Impact of signed message replay Reject, consensus to leave as "Low" 1221: ABNF: Sender = Originator / Operator Accept, Dave will give Jim a list of changes Base issues: 1183: Should we have an r= tag in either the signature or key record Open, take to mailing list 1184: Develop plan for transition of multiple crypto algs (a=) Open, take to mailing list 1185: Transition sha-1 to sha-256 Accept, proposed wording 1193: instead of signing the message, sign the hash Open, take to mailing list 1194: whitespace in signature? Accept, check grammar for CFWS vs FWS 1195: 3.4.6 Example (Canonicalization) Open, Hector must provide text, Paul will describe examples he'd like to see 1196: Upgrade indication and protection against downgrade attacks Open, some support for list of what I sign, some think it doesn't matter; security area suggest that verifier decides what's OK 1200: MUST vs SHOULD in Verifier Actions section Accept, Eric will propose text changes 1201: change the syntax from SPF compat to human compat SSP issue, deferred until then 1203: extendable RR records Accept, editorial issue for Eric 1204: issue with DKIM simple header algorithm and milter-based implementations Accept, Eric will add text warning about this issue with "simple" 1215: clarifications on use of l= tag Close, Eric has edited text 1216: signature h= and z= tags Open; clarify, h= required, z= optional and diagnostic, independent (decoupled); take to mailing list 1222: ABNF: Sender = Originator / Operator Accept, Dave will give Eric a list of changes 1224: DKIM and mailing lists Open, continue on mailing list 1226: 512 too short? Accept, use Russ's text 1227: bunch of nits for base Accept, editorial issues for Eric 1228: Why is s= REQUIRED? Reject, consensus NOT to have default selector 1229: z= field and EAI wg Open, investigate EAI work 1230: selectors and key rollover Close, leave as is, ASRG may discuss in BCP 1231: some process-problematic references in base Open, must address as RR doc forms (Authentication-Results already handled) 1235: Clarify delegation to 3rd parties Accept, Eric will propose wording to clarify 1236: Analyzing Failures: List of Possible Reasons Accept, Eric will edit Extra: x= and clock skew Resolution unclear; remove x=?; recommend (secure) NTP? We need to open an issue in the tracker for this one. New issues, not covered in the meeting: 1247: threats... (EKR) review of threats-01 Accept, Jim resolving, reviewing with EKR 1255: base... optional exponent needed or not? Open, discuss on mailing list --------------------------------------------------------------------