[00:00:45] MALBEC joins the room [00:03:56] MALBEC leaves the room [00:04:34] MALBEC joins the room [00:04:41] MALBEC leaves the room [10:45:36] MALBEC joins the room [10:50:42] fenton joins the room [10:51:32] fenton has set the subject to: DKIM WG at IETF 75 [10:52:25] mattiasa@su.se joins the room [10:57:32] Barry Leiba joins the room [10:57:41] Hi, remote folk. [10:58:02] Jim, are you listening to the audio? Is it working OK? [10:58:06] hi barry [10:58:13] the audio seems fine from here [10:58:46] David Cooper joins the room [10:59:09] sorry, I was off making coffee... [10:59:16] franck.martin@jabber.org joins the room [10:59:48] cyrus joins the room [10:59:49] sm-msk joins the room [10:59:51] Doug_Otis joins the room [10:59:53] yes, audio sounds good [10:59:54] can hear you fine... [10:59:56] I can hear you [10:59:57] fine [11:00:03] jimsch joins the room [11:00:06] cyrus leaves the room [11:00:14] Chris Newman joins the room [11:00:18] DKIM WG starting. I'll be scribing. [11:00:28] people still filing in [11:01:05] Agenda bashing [11:01:34] Working group's chartered work is basically done. We're discussing where we go next, i.e. updating base spec and movement toward standards. [11:02:05] Document status: errata is in RFC editor queue, ADSP is in the editor queue, overview is RFC5585, deployment is in WGLC. [11:02:19] WGLC ends 7 August [11:03:20] sm joins the room [11:03:30] Possible topics for "where we go next" discussion: Do we want to update DKIM base? Is DKIM base ready for that? Do we have enough experience to know it's stable? Should we eliminate features to streamline? If so, which ones? Do we have good stats on which ones are in use? [11:04:25] "mics open", feedback from jabber? [11:04:41] sean.s.shen joins the room [11:04:59] how many people are there in the meeting room? [11:05:08] Tony Hansen: In favour of moving to draft standard. Although 4871 took a while to get out, it has seen sufficient significant use to become draft standard. [11:05:15] About 25. [11:05:46] Tony Hansen: We have an errata that needs to go out, which reset the clock, but given the time it takes to produce an update this is probably not an issue. [11:06:13] Tony Hansen: Biggest question -- what features are being used? [11:06:49] Tony Hansen: We know the thing interoperates, but we need details about specific options of the protocol that are in use. [11:07:29] J.D. Falk joins the room [11:07:47] Mic: Aren't the results of the interoperability tests sufficient to demonstrate interoperability? [11:07:48] Tony Hansen: Dave recently circulated a couple of surveys (one for signing, one for verifying) to indicate what you're using and how you're using it. We need people to complete these and return them. [11:09:17] Doug Otis: I originally argued against "g=", but one of the arguments for it was a way to constrain what someone could do with a key. [11:09:21] Mic: How many deployment reports have been received? [11:09:34] fenton: roger, when doug's done i'll ask [11:10:29] Barry Leiba: (answering Jim's first question) Refer to Lisa's interop draft. [11:10:38] Paul Hoffman: Depends on the AD's preference. [11:11:29] Pasi Eronen: Concurs with Barry; when it comes to the IESG, others will also look at the interop reports, according to the draft. [11:11:46] J.D. Falk leaves the room [11:11:54] J.D. Falk joins the room [11:12:02] Pasi: If you take something out of the base spec, people will want to know who was using it. Would prefer something not too old. [11:12:48] phru8648 joins the room [11:12:50] Tony: Interop was held almost two years ago. There have been a few changes made to the document since then and some clarifications that came out due to the interop event. Not sure that everyone made changes because of those results. I would like to have another one. [11:13:13] Pasi: Could be a combination of old and new data. [11:13:46] BTW, it is not about interop tests. It is about what is actually happening in the wild [11:14:08] Because interops tests are restricted environments [11:14:13] Dave Crocker (answering second question from fenton): Very few responses, not sure I'm getting them all. Survey has been out for a few weeks, not even a trickle of responses. An online form was proposed (Murray volunteering); will be posted when it's ready. [11:14:37] Dave Crocker: Some people have missed the fact that we want data about actual use, not implementation details. [11:15:13] Dave Crocker: In the survey for verification, there's a portion called "Interoperability summary", about how DKIM is used. Perhaps this could be better worded. [11:15:51] Dave Crocker: If you have an operation or an implementation, please provide or encourage more feedback. [11:16:34] Paul Hoffman: We've already gone into the second part of Barry's question about going to draft standard. What do we mean by "update"? Are there more clarifications needed beyond the errata document, or are we talking about opening up whole new issues? [11:16:41] Barry: Depends on what the working group feels needs discussion. [11:17:11] Barry: Would not recommend another interop event, but it's up to the WG as a whole. [11:17:29] Paul: We shouldn't be going to draft standard if we think there are things that need updating. [11:17:43] Barry: True, but it should be discussed. [11:18:10] Tony: Regarding having an online repository for this info, the IETF tools site has stuff for doing this sort of work if we want to use it. [11:19:39] phru8648 leaves the room [11:19:56] Dave: There's Wiki software in use at dkim.org, but it's currently only available for somewhat closed (for now) activity that may even migrate to the IETF web site. DKIM activity could gain access to an instance of that software, but I'm unclear on how it could get used. IETF's version isn't very friendly. What activity do we have in mind for this? [11:20:34] (general chatter about whether or not this work is appropriate for a Wiki) [11:21:07] resnick joins the room [11:21:31] Lucy from IETF: What's available is not a Wiki, it's "Trac" which is a combination of SVN, task tracking, other tools. [11:21:59] IMO, learning to use a wiki to generate an interoperability report presents a bit more of a barrier to entry than just editing the text files that Dave sent out. [11:22:40] Barry: appears to be consensus that we want to move toward draft standard. (polling; verified) [11:23:20] Barry: Given consensus, what do we need to do to the spec? [11:23:57] Doug Otis: Portions of the errata that made me nervous is that part of the use of DKIM will involve the presentation layer that this group is not involved in. We don't have a good understanding of how it will be used. To say we're done and all these features are in place is wrong; we don't know. It's going to take time to figure out. [11:24:09] Doug Otis: We need to work with another group that deals with presentation to work out those details. [11:24:27] the presentation layer won't be "standard" for years, if ever [11:24:34] metricamerica joins the room [11:24:39] acceptance policies won't be "standard" for years, if ever [11:24:42] Doug Otis: How do we go about using DKIM to establish acceptance policies? Whitelisting presents replay abuse difficulties. There are elements of DKIM that could be used to mitigate those sorts of problems. [11:24:43] yao joins the room [11:24:45] doug's suggesting we wait forever [11:24:55] Either Murray is an incredibly fast typist, or there is a lot of delay in the audio stream. [11:25:03] I'm a fast typist. :) [11:25:19] Barry: This could be an area the working group could take on in the future. [11:25:27] metricamerica leaves the room [11:25:58] metricamerica joins the room [11:25:59] tonyhansen joins the room [11:26:01] Dave Crocker: There might be some presentation layer things that could be explored. [11:26:04] Reputation <> how things are presented. [11:26:20] I mean != [11:26:31] DKIM is also mentioned in SIP documents [11:26:48] Dave: There are directions of additional work we could tackle based on DKIM, such as something that came up at EAI: Using the DKIM hash as a means of doing message comparisons. [11:26:54] Jim: I wasn't equating them, but putting them as two things that we might do. [11:27:13] alexmcmahon joins the room [11:27:35] Dave: If the signatures both verified, are they the same message? This is a path of using DKIM we haven't talked about that might be worth exploring. [11:27:38] Murray: shouldn't your handle now be "cm-msk"? [11:27:51] yeah, it should. i was in a hurry. [11:28:11] Stephen: Yeah, but SIP mentions everything. [11:28:18] sm: Which SIP docs? [11:28:37] Pasi: Agrees that we don't know how DKIM will be used, so maybe we should be conservative about what we remove. [11:29:00] Tony Hansen: There is a difference between "not widely used" and "not used at all". [11:29:00] I don't recall. It was something about security published over the last year. I think it was to sign the SIP headers. [11:29:09] Barry: What does "some use" mean? [11:29:22] To clarify: "conservative" means "if in doubt, don't remove" [11:30:09] Tony: In my opinion, if the option's there and nobody's using it, I'd rather see it used in real operation for it to count. [11:30:47] Barry, RFC 5039. [11:30:57] Pasi: About implementation reports, I don't think the IESG would value tests in controlled environments. [11:31:18] Barry: There's a difference between implementation and having the feature in use. [11:31:32] sm: thanks [11:31:34] semery joins the room [11:31:41] Paul Hoffman: The hidden thing nobody is mentioning -- Do people use this for whitelisting, which is what we hope the value would be? [11:32:50] Paul: At the interop event, and since, the large mail receivers have said "We might be using DKIM but we don't want to tell you", and one said "Yes we use DKIM but we won't tell you which parts". I assume all features in the DKIM spec are probably used in signing based on observation. [11:33:20] Paul: If we don't know which verifiers are using these, I believe we can't say what's useful. We need to seriously rethink what we mean by "interoperability". [11:33:37] Not all features are visible in the signature -- some are only visible in the key records. [11:33:39] what kinds of large verifiers do you mean? [11:33:40] John S joins the room [11:33:45] Paul: There are features that can be tested as interoperable, but people turn them off because the 10% that doesn't interoperate causes communication to fail and the feature's not that important anyway. [11:34:04] most of the large ISPs are being pretty open about whether or not they're verifying (although agreed they may not be explicit about which features they're using) [11:34:28] Paul: Some participants at the interop may not have been looking at the signatures, just looking for specific feature implementations. We may simply not know. These weren't real world tests. [11:34:33] I talk to big ISP folks all the time, and what they're primarily cagey about is the reputation layer [11:34:35] (Barry relaying from Jabber) [11:34:50] Paul: (re large verifiers) AOL, MSN, Gmail. [11:34:51] (btw, MALBEC = ellen siegel... not sure why my new install is showing machine name rather than profile ID [11:35:30] Barry: It seems odd they would be worried about exposing use of DKIM; this might seem to suggest they feel DKIM has a hole in it that we have ignored. [11:35:58] Both Yahoo! and Gmail have online information telling that they're using DKIM for something [11:36:04] Paul: At the interop, we were worried too many deliberately bogus signatures might reveal how receivers are using DKIM. Happy to get large ISPs saying they are verifying. [11:37:03] Pete Resnick: We're talking about moving the base spec to draft standard. I disagree with Pasi; it should not necessarily be the case that we get beyond two masters-level implementations or use operationally. Qualcomm was implementing DKIM, just not doing anything with the information. [11:37:35] Pete: The question is: Is the spec implementable in an interoperable way? Operational questions should not impede movement to draft standard. [11:38:02] Barry: If lab tests are done by people in the working group that developed the spec, it's not fair to say it's implementable and interoperable. [11:38:18] (banter about the above) [11:38:33] For example, http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html [11:38:42] Dave Crocker: We need to track all the topics we're touching on here. [11:39:59] Dave: What we have going on here is an imposition of a move-to-draft model that covers what we like, not the actual rules. We need to be careful about that. The rules both allow us to do this and don't. RFC2026 sets criteria for software development and use: two interoperable and independent implementations. Says nothing about whether or not they're involved in spec development. [11:40:53] Dave: The actual barrier defined in RFC2026 is quite meaningful and very low. I would like a much higher bar, though this is not in the rules. [11:40:59] Dave: Who gets to set the bar? [11:41:31] Dave: The people choosing to ask for standards progress get to decide what the bar is. [11:42:26] Dave: The interop event had no products, i.e. fielded code. Enough to satisfy the lower barrier. Many of them now do have fielded product, so their implementation details would be valuable. [11:43:08] Dave: We get to decide, except that Pasi recommended (i.e. required) something more substantial than that. Pete's definitions come from outside the working group which go beyond the rules. We should clarify this. [11:43:17] Dave: The question of what to remove is also a place for some choice. [11:43:37] Dave: Current rules seem to say: If the feature is not used at all, it must be removed. If it is used some, this is a fuzzy area. [11:43:47] messagesystems, port25, strongmail have DKIM implementations, their support/customers could give insight [11:44:01] Dave: "We should keep stuff because someone might use it" imposes a cost in maintenance of unused features. [11:44:12] fujiwara joins the room [11:44:29] (chatter about Lisa's draft and its semantics) [11:44:47] Chatter? CHATTER? [11:44:59] Pointer to Lisa's draft? [11:45:04] yes chatter, i couldn't keep up :) [11:45:38] http://tools.ietf.org/html/draft-dusseault-impl-reports [11:45:45] ja joins the room [11:46:13] Stephen: Hearing more or less "yes" to moving forward, but there's vagueness about criteria under which we would or would not remove features. [11:46:30] DKIM-Signature: v=1; a=rsa-sha1; d=facebookmail.com; s=q1-2009b; c=relaxed/relaxed; [11:46:34] Barry: Concurs with "if it's not implemented, remove it", but we have implementations that provide all the features. [11:46:46] Barry: For example, how does a verifier use "l="? [11:47:57] Murray: There are policy extensions around things like "l=" to be considered as well. [11:48:01] Barry: That would count as "being used". [11:48:29] most of the features I've found to be in question are key record features. If no one sets g=, can it be kept? [11:48:29] Doug Otis: I didn't see Mike Thomas on the jabber, but he also said he was using some of these features in an unusual way inside Cisco. [11:49:07] Barry, for Mike: We talked about all of these, we came to consensus, we should assume they're all in use. [11:49:56] Stephen: Would like to resolve this without rehashing it all on the list again. [11:50:12] Stephen: We need consensus about what constitutes use of a feature. [11:51:14] Tony Hansen: A couple of examples from his usage report: The key value "g=" is supported in the verifier. None of our customers set that value. [11:51:32] Barry: Personal view: If your software provides it and nobody uses it, it's not in use. [11:52:12] Tony: If you map data into key records and none of them have that value, is the feature in use? [11:52:19] Barry: A DNS crawler could produce useful results. [11:52:22] john.levine joins the room [11:52:42] Tony: Agrees, and we could then see what key record features are being used. [11:52:53] Crawling DNS entries would require that someone collect a large number of selector names. [11:53:02] Jim: yes. [11:53:15] I thought one would take them from collected email, and then look. [11:53:42] Stephen: When we have some implementation reports, we can use that to determine which things are in use. [11:54:29] Doug Otis: When you're talking about "g=", you're talking about a security feature. Useful for limiting third party signing. I'm happy to get rid of it. We could announce it's going away and see who squawks. [11:54:57] Barry: Dave did this on ietf-dkim for each feature. (listing them) [11:57:58] Dave Crocker: Suggests: There are ways of categorizing the various tags in DKIM signatures and records into certain categories, something like "x=" in the category of "relatively common protocol mechanics characteristic", fairly well understood mechanism (doesn't say it is or isn't appropriate to keep). [11:58:18] Dave: We omit those features without which DKIM wouldn't function. [11:58:50] Dave: Other categories: Those that request the recipient to enforce security controls that are within the bounds of the signer, such as "g=" and "x=". [11:59:46] Stephen: Is it a question of use/non-use vs. these categories? [11:59:57] Dave: Tyring to keep these categorizations separate, at least at first. [12:00:30] Stephen: I agree this would help, but would it help us move toward standard? [12:00:49] meta meta meta [12:00:55] lager lager lager [12:01:31] Barry: Discussing the features in that manner can't help but feed into whether or not we keep them. "x=" is a good example; almost by design, it's being used by everyone. Whether or not it's useful is a separate question. [12:03:07] It might be good to consider whether removal of x= and/or g= represent a change that would cause us to stay at PS. [12:03:09] Dave: People are locked into their positions and scripts. What I'm trying to do is break us out, as a group, from the scripts we're locked into. We need to step back from those positions, and try to come at it from a new angle, removed from the details. [12:03:24] Jim: that was my point, above. [12:04:10] Barry: The choice of the categories itself is tricky. [12:04:32] Rickard: It's not possible to find the DKIM record with a crawler because it's an arbitary selector. [12:04:39] Barry: We would collect selectors from signed mail. [12:06:05] Paul: I think we know what our goal is, which is to move to draft standard. We have a spec that tells us how to do it: "Do your best effort; if you're not sure you're doing it right, ask for help (from the AD)". In none of my experience with this work has the IESG said "This was totally wrong, go try again." I propose the correct way is to remove nothing unless we're sure nobody's using them. [12:07:27] Barry: Would like to hear from SM about this. [12:07:40] Barry: Or maybe it was Steve Atkins... [12:07:41] resnick leaves the room [12:08:25] Stephen: Any other input? Or just take it to the list? [12:09:46] Lucy, ISOC: On the "be liberal" side (Paul's point). Had recent experience with deployers and DKIM. We have yet to get any real traction aside from getting it implemented in list software. In almost every case they didn't have any use for DKIM in general, but it was very interesting in several corner cases. We don't have any sense of how the various knobs will get used; if you take them away, people will pervert them. [12:10:22] Barry: One of the arguments for removing features is that DKIM is too complex, should be simplified. [12:10:38] Lucy: You think they think it's too complicated, but you're not clear on how they'll actually use it. [12:10:45] what is the use that we thought they were going to put it to? [12:11:15] I thought it was intentionally generic... [12:11:47] Lucy: They assumed DKIM would be good for validity of an incoming mail message. They don't think it's useful for that, but it might be useful for exchanging information between known parties securely. [12:12:03] Lucy: Establishing credentials of the sending entity. [12:12:45] ah, so that's the certification (or self-certification) model, which dave crocker and I were talking about at MAAWG a few years ago as a first step towards encouraging implementation [12:12:58] Dave: We don't talk a lot about the larger context of how people think DKIM will work. We mostly hear about use in finding phishers. What it's for is creating a trust infrastructure. [12:13:05] (don't bother reading what I read, dave put it better) [12:13:11] er, what I wrote [12:13:23] Lucy: Yes, phishing is the immediate assumption. The potential use cases are more complex. [12:13:43] Dave: This is because of stronger promotional voice for the anti-phishing uses. The other message has been there all along though. [12:13:54] but this part's for the mic: is it time to document some of these use cases yet? [12:13:55] Lucy: So be careful what you strip out until we see how people will really use it. [12:14:14] Dave: This logic fed the complexity of the OSI protocols. [12:14:21] I'm not personally in favor of all the features that are there (for example: t= and x=) but I don't see the presence of features such as this as stifling deployment at all, and I'm willing to believe that there are use cases for these that I haven't considered. So I also favor keeping features unless they're truly unused (which would require them to be removed). [12:14:28] JD: want to say any more about that before I channel you? [12:14:40] anti botnet spam? as 70% of spam is from botnets? [12:15:13] Dave: There's a philosophical difference between the two sides of this drop/don't-drop debate. One is "do whatever it takes to get to draft standard". [12:16:01] Dave: The other side is a quality control issue: There's lots of stuff in RFC4871, the keeping of which has a cost if we move forward with it. [12:16:18] Dave: Each side of that debate has legitimacy. We ought to at least be clear about what's driving us. [12:16:33] Dave: "Just get it done" is different from "Be afraid to drop things". [12:16:41] while you're channelling, re Lucy: every anti-spam measure since forever has been misreported as a magic bullet. In the WG I never heard any serious use case other than recognizing mail from people you already directly or indirectly know. [12:17:11] Lucy: Not saying that, but unless you're very sure your deployed users understand all the use cases, I'd leave them some latitude to explore their options. [12:17:12] knobs can always be added later if there is a clear need for them [12:17:16] but there sure was a lot of confusion by people who were only tangentially involved [12:17:43] Dave: Protocols often need knobs added. The question is: Does it need these particular knobs? Do they need to be retained from an old environment that didn't use them? [12:18:12] I'm hearing several voices in favor of keeping most features, and apparently a smaller number that favor removing little-used features. Would an informational hum be useful? [12:18:22] Dave: These are usually not the ones we want later. SNMP security is a good example. [12:18:27] Barry now channeling jabber. [12:20:12] piling onto my earlier point: just about every time I hear about a new group of people starting to consider what DKIM can do for them, they go through a very similar thought process: first getting past the popular press accounts, THEN digging into what DKIM actually does. an "official" collection of use cases & deployment recommendations might help. [12:21:08] not clapping for "keep all" [12:21:12] keep [12:21:15] clapping for "remove some" [12:21:17] I think some should be removed [12:21:42] clap: remove [12:22:40] Barry: There's not strong consensus either way. (Question was: For features that are implemented at all, keep or consider removal?) [12:22:57] Barry: Now, what criteria should we use to decide to remove features? [12:24:03] to remove features, suggest continuing with (and expanding) dave's survey, then giving more weight to features used by verifiers than to unverified features used by signers [12:24:10] Dave: I keep citing the category that's most interesting: Trying to recruit the recipient for enforcing internal controls. Would allow us to talk in terms of concepts rather than switches. [12:24:42] Pasi: Procedurally, the baseline we have is RFC4871 and the errata RFC (approved), so if we achieve consensus to remove, that's fine, otherwise it stays and that's the default. [12:25:01] Barry concurs with JD's point. [12:25:10] Tony says it's the opposite. [12:26:59] Barry: We should gather the information rather than speculating about it. [12:27:22] re l=, no we don't [12:27:28] Verifiers don't need to implement l= [12:27:45] agreed, what to do with it afterwards is more interesting than whether the code sees it's there [12:27:49] fenton: Why not? [12:28:12] You need to implement l= to be able to verify. Then there's the policy layer to think about. [12:28:31] Verifiers can not implement l= if they're willing to accept only signatures that cover the entire body [12:29:13] Doug Otis: In talking about removing and re-adding features, adding would be problematic if you want acceptance based on a feature where the verifier won't recognize it. I don't know what you'd achieve if you have no expectation of a new feature being used. [12:29:38] Agree with Doug [12:30:44] Stephen: Anything we can do to encourage people to provide the feedback we need? [12:30:54] Barry: Get the word out, have people fill out the forms. [12:31:22] Should we have a list of respondees so that we don't harass those who have already responded? [12:31:26] Stephen: Timeline to get some of this stuff done? [12:32:12] Barry: Timeline can be driven by the fact that we can't touch the updated spec for six months. [12:32:41] let's wait a MAAWG meeting to happen, so you can circulate forms there? [12:32:48] Barry: March IETF would be outside that range. [12:33:16] MAAWG in October, February [12:33:24] so that's easy [12:33:38] Stephen: Do we need to meet again? [12:33:50] Do we need to discuss actual rechartering text? [12:33:58] Barry: Probably in Anaheim> We'll figure out Hiroshima later. [12:34:23] Barry: We can discuss rechartering text on the list. [12:34:38] Pasi: Current charter text is quite old. All of the work items have been completed. [12:34:56] Barry will take that update on as an action item. [12:35:02] Doug_Otis leaves the room [12:35:03] Wrapping up. [12:35:10] sean.s.shen leaves the room [12:35:13] Thanks, all. [12:35:16] (blue sheets) [12:35:31] Who's "metricamerica"? [12:35:40] semery leaves the room: Disconnected [12:35:43] metricamerica leaves the room [12:35:46] jimsch leaves the room [12:35:53] sm-msk leaves the room [12:35:53] yao leaves the room [12:35:55] Barry Leiba leaves the room [12:36:09] MALBEC leaves the room [12:36:17] David Cooper leaves the room [12:36:28] franck.martin@jabber.org leaves the room [12:36:46] sm leaves the room [12:36:55] john.levine leaves the room [12:39:21] J.D. Falk leaves the room [12:43:47] fenton has set the subject to: DKIM WG at IETF 75 (concluded) [12:44:07] fenton leaves the room [12:48:11] John S leaves the room [12:51:01] mattiasa@su.se leaves the room [12:58:39] Chris Newman leaves the room [13:15:28] Doug_Otis joins the room [13:16:03] Doug_Otis leaves the room [13:17:35] alexmcmahon leaves the room [13:22:21] tonyhansen leaves the room [13:58:45] MALBEC joins the room [13:58:49] MALBEC leaves the room [14:07:57] MALBEC joins the room [14:08:01] MALBEC leaves the room [14:12:05] Exodus joins the room [14:12:10] Exodus leaves the room [14:12:43] Malbec joins the room [14:12:46] Malbec leaves the room [15:05:36] ja leaves the room