[14:37:21] ehsiegel joins the room [14:40:34] ehsiegel leaves the room [16:44:27] Doug Otis joins the room [16:44:39] Doug Otis leaves the room [18:37:19] sm joins the room [18:38:29] sm leaves the room [18:48:31] sm-msk joins the room [18:49:15] sm joins the room [18:53:17] sure is quiet in here [18:54:15] ESiegel joins the room [18:54:21] sm-msk has set the subject to: DKIM WG starts at 13:00 CST [18:54:31] hey ellen [18:55:04] Doug Otis joins the room [18:55:30] hi [18:55:34] Based upon the prior sesson, the sound level in this room is rather low. [18:56:42] fenton joins the room [18:56:50] huguei joins the room [18:56:57] Dave Winter joins the room [18:56:59] sftcd joins the room [18:57:12] hey jim [18:57:46] sir [18:58:36] David Cooper joins the room [18:59:10] ehsiegel joins the room [19:00:25] We're on audio channel 7, right? [19:00:29] i'm not getting any audio... is it just me? [19:00:31] supposedly [19:00:34] dead here too [19:01:00] there it is [19:01:01] faint [19:01:08] It's not dead, just very low and noisy. [19:01:15] lellel joins the room [19:01:27] rlbob joins the room [19:01:35] prussell-nd joins the room [19:01:37] if you want Dave Cooper to say something at the mic preface it with (mic) [19:01:39] much better now... [19:01:50] Doug Otis leaves the room [19:01:52] RLBob is scribing in jabber today [19:01:55] I could hear Barry just barely at first, but Stephen hardly at all [19:01:56] i can hear the chairs only [19:02:07] Doug Otis joins the room [19:02:12] no one's talking yet, starting in 1-2 min [19:02:24] Stephen, say something as a test [19:02:31] I am basing that by listening to the prior meeting. [19:03:18] Heard that [19:03:20] mics ok for remote folks? [19:03:22] much better [19:03:40] there's a hum in the background but it's not bad when people are talking [19:03:54] Doug Otis leaves the room [19:03:56] eric joins the room [19:04:13] Doug Otis joins the room [19:04:16] starting now [19:04:24] robert joins the room [19:05:11] These slides: http://www3.ietf.org/proceedings/08nov/slides/dkim-1.pdf [19:05:28] on agenda bash [19:05:38] on status [19:06:33] bl: document status, 3 RFCs, overview and SSP in IESG, deployment is WG draft [19:06:50] pasi(the AD): started reading overview, will reply [19:07:07] pasi: gave comments on SSP, awaiting new draft [19:07:22] sf: should be easily addressed [19:07:30] John L has a new draft of SSP ready for release [19:07:38] bl: unless recharter happens, won't meet at next IETF in SF [19:07:51] jim: yay! ship it! [19:08:12] tony: base spec errata [19:08:20] uoch. [19:08:20] fujiwara joins the room [19:08:23] ouch too [19:08:47] many errata have been filed, many from interop event a year ago [19:08:50] Barry Leiba joins the room [19:09:24] speak to contentious ones [19:09:38] 1383: wildcarding in g= value [19:09:38] please give errata numbers so we can chase them down on the web site [19:09:43] thanks :) [19:10:03] some impls didn't do them, or assumed there was only one, etc [19:10:18] Can someone remind me the URL for looking up errata? [19:10:21] rather, there is only one, can't have multiples [19:10:26] http://www.rfc-editor.org [19:10:42] john.levine joins the room [19:10:44] http://www.rfc-editor.org/errata.php [19:11:08] room: the sound is very weak, can you speak directly into the mike please? [19:11:18] two choices: revise this erratum re multiples, or decide to support them [19:11:41] eronenp joins the room [19:11:43] same [19:11:53] there's a low buzz the speakers have to overcome [19:11:56] better [19:12:16] much better [19:12:17] much beter [19:12:21] The original intent was to accommodate local-parts like fenton+dkim and fenton+ietf by using g=dkim* [19:12:34] the sound stream level is very low. [19:12:34] I'd be interested in the other uses though [19:12:37] (fenton*) [19:12:42] implementing multiple stars is much harder than a single one. [19:12:54] I mean using g=fenton* [19:13:16] unless it adds some significant advantage, i don't see a good argument. [19:13:31] pasi: if spec is clear that only one is allowed now, then shouldn't be changed via erratum [19:13:32] agreed, expensive feature, little utility [19:13:43] i think the only counter-argument is that people will assume they can be used liberally, without reading the spec. [19:14:04] tony: errata process is supposed to gather desired changes [19:14:09] just because wildcards are common use [19:14:20] hey, is anyone listening to us? [19:14:21] propose choice 1, any objection? (none heard) [19:14:30] will confirm on mailing list [19:14:40] No on multiple stars. Add a note to advise safe format. [19:14:50] (where are the slides?) [19:14:58] choice one is to allow a single *? [19:15:19] 1378: is "a=" required or optional? [19:15:32] None has special meaning. [19:15:40] resnick joins the room [19:15:41] semery joins the room [19:15:55] Doug Otis leaves the room [19:16:13] kivinen joins the room [19:16:14] Doug Otis joins the room [19:16:30] The spec is very specific about a single star, if we change it now we create an interopability issue [19:16:51] chatroomers: please preface comment with mic: to have it read out loud here [19:16:57] my vote is to have a= optional [19:17:14] 1378: 3.3 says optional, 3.5 says it's required [19:17:23] Where are Tony's slides? [19:17:45] i got them from the email he sent to the list a week or so back [19:17:45] davec: don't trust defaults, this isn't expensive to require [19:18:10] Tony gave them to us too late to get uploaded. Let me see if I can upload it now. [19:18:22] phb: often people assume that default things never change, so prefer to require [19:18:29] Jim: https://datatracker.ietf.org/meeting/73/materials.html [19:18:45] tony: would this change be permitted as erratum? [19:18:59] sf: let's not worry about that now [19:19:37] so far "required" outnumbers "optional", i'm ok with that [19:19:46] pasi: correcting mistake in spec should be done via erratum in any case [19:20:04] our implementation requires it [19:20:12] per the current spec [19:20:29] phb: this is confusion rather than inconsistency ... [19:20:45] The slides are up now. [19:20:51] tony: any signing implementations not using a= ? [19:20:58] PHB joins the room [19:20:58] we always use a= when signing, don't know about others [19:21:18] I'm not sure if people are using a=, it's not something that I look at a lot... [19:21:52] http://www3.ietf.org/proceedings/08nov/slides/dkim-5.pdf [19:22:31] bl: take question to list [19:22:46] thx John [19:23:23] err 1532: what if a DK (4870) DNS record is found, and has empty g= which is ambiguous [19:23:25] do people who run reflectors have log data they can mine? [19:23:38] Main issue is the example given in RFC 4870 [19:24:37] Lisa joins the room [19:24:57] various options: add compatibility note, do nothing, or specify workaround ... [19:25:28] ESiegel leaves the room: Replaced by new connection [19:25:57] Doug Otis leaves the room [19:26:06] Doug Otis joins the room [19:26:09] MIKE: do we also let them read records without v=? [19:26:13] (mic) our implementation does hte third thing [19:26:16] suggestion on list for updated text per slide ... [19:26:51] yes, absence of v= means act like it's a DK record [19:27:08] (it's an option, actually) [19:27:43] i mean: our implementation can be configured to treat the absence of v= to mean "treat this like a DK record" [19:27:55] ok [19:27:58] Doug Otis leaves the room [19:28:08] err 1596: a new one: dealing with WSP in bh= values in hash calc [19:28:12] Doug Otis joins the room [19:28:32] MIKE: I believe this is already handled in the overall ABNF. [19:28:49] 3.5 b= text talks about handling WSP [19:28:53] White space is ignored at the beginning and end of ALL values. (But I'm doing this from memory) [19:29:18] sec 3.2 definition of tag-val talks about wsp in value but not around value [19:29:54] see abnf for tag-spec [19:30:18] (mic) does the ambiguity matter? if in bh= and b= you crush whitespace in the value, then whitespace before and after the tag-value gets dropped in any case even if the ABNF is ambiguous [19:30:19] sec 3.5 sig-b-tag data mentions FWS as being separate from data [19:30:24] but that still doesn't tell us whether to delete it when checking the signature [19:31:21] tony: conclusions from spec sections: tag-val and sig-b-tag-data don't include surrounding wsp [19:32:01] but base64string def includes FWS in its input [19:33:11] barry: nevermind, i get it, disregard previous (mic) remark [19:33:14] so, "with value of 'b=' tag deleted" could mean different things [19:33:23] ok [19:33:40] concur with the erratum [19:34:17] erratum text proposed: add "including all surr wsp", and change base64string def to exlcude FWS [19:34:24] Barry Leiba leaves the room [19:35:21] http://www3.ietf.org/proceedings/08nov/slides/dkim-4.pdf [19:35:35] new topic [19:35:54] tony: deployment draft [19:36:21] turned inside out to be activity oriented, refocus on domain-specific info [19:36:32] intend to have WGLC before next IETF [19:37:09] mic: speak into mike please, you're fading out [19:37:15] looking for feedback from deployers ... [19:37:32] thanks [19:37:37] heh "complaining about the noise" [19:37:37] section 2: using dkim as part of trust assessment [19:38:16] doing trust assessment is different from mistrust (badness) assessment we usually do [19:38:41] rlbob: ehhhhh [19:39:19] rlbob: a group of academic users are starting (more later) and this is something they struggled with [19:39:42] rlbob: not obvious at all [19:39:55] The only area that this group has missed is how "on-behalf-of" should be used with respect to dealing with replay abuse and reputation services. [19:40:12] sorry mic [19:40:59] that was an "errrrm" I think steven [19:41:40] rlbob: how many pages do you want? [19:41:53] robert leaves the room [19:42:01] (mic) d= and i= represent subtly different things, and I think that different reputation services may reasonably use different things [19:42:52] d= is definite, but for large domains, i= is essential. [19:43:17] That is why adsp misses the mark. [19:43:37] davec: text was intended to elicit comment, so please comment on mailing list [19:43:59] section 3 on key management [19:44:04] Lisa leaves the room [19:44:05] You don't need to ask. : ) [19:44:31] tony: think that this material is less contentious [19:44:45] tony: sec 4 on DKIM signing [19:44:59] 4.2 on mailing lists is probly most contentious [19:45:18] bl: charter says mailing list effects must be considered ... [19:45:57] tpa could address this problem in a secure fashion. [19:45:57] yeah there will be a lot about mailing lists on ietf-dkim [19:46:07] davec: definitely issues are coming up in the real world [19:46:50] tony: people ask questions indicating lack of understanding about signature effects [19:47:16] sec 5 on verifying less contentious ... [19:47:19] (mic) is this overhaul a published draft (so that we can provide proposed text that fits) or is that coming? [19:47:27] (mic) I have recently run into a few domains that are rejecting messages because of broken DKIM signatures, and we need some text somewhere that advises as strongly as possible against that. [19:47:28] sec 6 on email agents [19:47:56] the draft is still pretty rough [19:48:28] tony: new version is "in the works" with all this stuff, will be out in "3 weeks" [19:49:05] bl: so should people comment on current version or wait for new one? [19:49:26] bl: suggest that commenters submit stuff now rather than waiting [19:49:54] jim - Dave's still @ the mic for you [19:50:02] thx [19:50:06] oops - not this Dave [19:50:23] this one:-) [19:50:33] davec: doc is still early, large segements of text welcome [19:51:12] agreement in the room with Jim's comment [19:51:16] sec 7 migration from DK, any other areas to cover? [19:51:43] sec 8 example uses [19:52:11] sec 9: ADSP, what should this doc say vs ADSP RFC? [19:52:36] that's the last slide [19:52:56] pasi: useful to have text regarding issues with parent domain check [19:53:00] PHB up next: http://www3.ietf.org/proceedings/08nov/slides/dkim-3.pdf [19:53:33] phb: certificate reference extension [19:53:55] objective: link DKIM key to a cert [19:54:11] Is NIST really a "brand"? :-) [19:54:53] allows use of trusted third party accreditation [19:55:16] paul h: what direction is this going in? [19:55:39] pbh: trying to match key in DKIM record to key in cert [19:56:21] can establish accountability to cert owner [19:56:26] Do we have any other examples of where we match the public keys found in two places? [19:56:29] can use EV certs with logos etc [19:57:14] jim: xml signatures do it in ds:KeyInfo's [19:57:20] propose extension to key record to hold URI pointer to cert and/or cert chain [19:57:25] semery leaves the room: Disconnected [19:57:48] Thx, Stephen [19:58:21] presumably URI is really URL ... [19:58:22] !amdnes [19:58:35] sorry, bad paste [19:59:06] bad paste=coloured teeth? [19:59:12] pbh: people will want to do this anyway, this will standardize it [19:59:44] jim schaad: no cert chain object in CMS, just bag o certs [20:00:05] pbh: don't want to invent cert chain format [20:00:53] (mic) Is there anything that needs to be done to protect against DOS attacks resulting from X509 URLs being attached to a lot of (perhaps properly signed) spam? [20:01:02] jim s: why a chain? may want different chains for different RPs, so just a bag (or set) [20:01:37] pbh: should this be a recharter item? [20:02:31] Perhaps some constraint on the URL that can be used there [20:02:43] re DOS attack: could be an issue ... [20:03:26] paul h: shouldn't be done using http pointers, should just include cert in DNS [20:03:57] barry said we don't need to bash the detail here, just the is this a good idea or not and if so, should we re-charter for it? [20:03:58] actually that was: include cert in the email message itself [20:04:44] sf: so is providing some means of linkage a good idea? [20:05:06] th: see utility of having secure logos [20:06:03] davec: would like some indication of use by receivers before going forward [20:06:41] bl: have asked about formal liaison with MAAWG etc, no conclusion [20:06:56] David Cooper leaves the room [20:06:57] bl: can phb ask people at APWG? [20:07:09] phb: sure [20:07:34] David Cooper joins the room [20:07:56] phb: have seen pressure from senders on adding trustworthiness, not clear about receivers [20:09:52] phb: would like to have incentives for enterprises to deploy, perhaps educating users that messages will have company logo attached will incent more professional messages [20:10:00] adding a logo isn't going to do much about stupid corporate email ;-) [20:10:38] paul russell: would clients really support this? [20:11:14] bl: not yet, but that's the question: if we standardize it, would they? [20:11:29] th: some software doing this in other ways today [20:11:35] mic, trendmicro supports this feature, but is done in a closed fashion. [20:12:01] I have seen commercial products with proprietary ways to do something like this. [20:12:09] phb: policy criteria being discussed in CAbrowser forum [20:12:44] A number of ISPs support displaying a Goodmail Certified Email icon... adding support for corporate logos doesn't seem that different. [20:13:00] charlie kaufman: does key record support this extensibility or future extensibility? [20:13:33] bl: no "experimental" tag names ... [20:14:29] davec: people already doing things like this in the world, so really have to consider whether it will be adopted [20:14:57] paulh: doesn't have to be done in WG, no method collision likely [20:15:32] sf, channeling murray: reporting extension [20:15:34] eronenp leaves the room [20:16:06] i thought it was dave crocker who said that actually :) [20:16:14] some "scattered" implementations of parts of proposal today [20:17:39] this is early work, so not too hard to rework as WG item [20:17:39] no, you got the basics, thanks [20:18:13] (mic) this one is DKIM-specific [20:18:18] bl: senderauth work being pursued as individual [20:18:27] sender-auth-header applies to lots of authentication schemes [20:18:34] (mic) yes [20:18:57] (mic) Most of the people that are taking action based on DKIM signatures [20:19:10] (mic) want some way to report to the sender what they did [20:19:24] (mic) This makes it scale reasonably [20:19:26] Klaas Wierenga joins the room [20:19:31] mic: The TPA draft has been presented previously. The TPA hashed label by the authorizing domain approach reduces support required to allow providers a means to authoritatively sign on behalf of other domains. This also removes the potential risks related to key exchanges, and does not require more DNS transactions than what is required to use CNAMEs as a means to allow providers control over the public key content. It also removes coordination between DNS administrators as currently required for either domain delegation or CNAME references. TPA can be established in a unilateral manner to handle message losses related to domain approved mailing-lists, as an example. Since the use of the TPA mechanism is also roughly analogous to vouch by reference, use of the vbr-info header as an example, could be used to signal the use of the TPA mechanism as well. It seems that at least one sentence of the DKIM charter needs to be changed before this approach can be handled by this working group. This effort may impact existing SSP efforts, so coordination within the WG seems desired. Questions? [20:20:05] The slides was in regard to the charter discussion. [20:21:58] thanks doug - barry's gone back to the slides now [20:22:22] eronenp joins the room [20:23:27] bl: any questions? (none heard) [20:23:53] bl: please read and comment on this as rechartered WG item [20:25:13] bl: further question is whether to go into reputation and accreditation [20:25:26] ASRG has been doing some work in this area [20:25:38] ie block lists [20:25:52] just to be clear - The chairs are not seeing the level of energy that'd be required to re-charter any of the 3 proposals which implies that the WG is likely to hibernate if nothing happens [20:26:15] davec: being intentionally provocative: much stuff going on, but not ready for standards yet [20:26:22] mic: when we were running DAC, we tried to come up with reputation stuff, didn't go anywhere. Reputation is certainly important, but it's way too early to standardize 'cuz we don't understand it well enough. [20:26:27] (i.e., I agree with Dave) [20:26:55] it's complex, fuzzy, incoherent at this time, need coherence to start standards process [20:27:51] davec: we should wait for pressure from industry for standards before jumping in [20:28:18] (mic) We're setting a high bar for the maturity of the work that this WG is pursuing, much more so than many other WGs. Is it reasonable for us to pursue things that would be initially experimental but later mature to standards track? [20:28:20] mic, dkim where i= represents an authenticated identity could scale better than what IPv6 block lists are likely to achieve. While Dave Crocker is right about being ahead of the curve, we should also be careful about preventing standardization as to what is authenticated. [20:29:04] aaron falk: find this surprising, as there was just a LC that seemed to result in claims that some constituencies aren't represented by industry approach [20:29:53] davec: block list work is done, work beyond that is rich, fuzzy, incoherent, etc [20:30:28] jabber folks - let's just do this discussion 1st - back to your comments then [20:30:28] Barry Leiba joins the room [20:31:16] aaron: questions on ietf list were about end-user empowerment, better failure notification, ietf tends to ensure that stuff is in there [20:31:29] Andrew Sullivan joins the room [20:31:37] aaron: where industry stuff may not do that [20:32:49] davec: user empowerment is cool, but we don't necessarily know how to do it in ietf very well [20:34:51] resnick leaves the room [20:35:07] mic: re Jim's comment, I don't understand what experiments would be appropriate here vs in ASRG which is supposed to be for research, after all. [20:35:31] phb: distinguish between reputation and accountability, accountability is handled by EV certs [20:36:56] phb: reputation is in the eye of the beholder, implying that standardization needed is moving reputation stuff about [20:36:57] te [20:38:56] andrew sullivan: perplexed by claim that standardization should wait, since DNSBL situation was that the world has already done it, there's no chance to change it [20:39:49] th: last quarter of ietf list thread seemed to be getting into how to make things better [20:40:36] th: really hoping that vbr takes off, maybe call for proposals aimed at BoF at next IETF? [20:40:52] bl: good idea, where to send that call? [20:40:58] MAAWG [20:41:15] th: ietf list, MAAWG, APWG [20:41:44] lisa d: IAB sends out calls for proposals sometimes [20:42:24] davec: codifying existing stuff is different than doing new stuff [20:43:17] davec: still not seeing pressure for new stuff [20:43:57] mic, there are different perspectives when talking about reputation. Advantages change when authentication provides increased granularity, as this reduces the clout afforded the larger domains. [20:44:15] Doug, you're fourth in line behind Dave. [20:44:50] davec: should require people to come with concrete proposal and base of support [20:45:25] Andrew Sullivan leaves the room [20:45:32] Andrew Sullivan joins the room [20:46:27] paul h: agree with dave c (!), discussion on ietf list was "how do I get unlisted from negative list", which is not worth implementing [20:47:12] paul h: no "DNSBL industry" [20:48:11] paul h: domain assurance council is indeed folded, btw, showing no base of support, WG could happen but would be waste of time [20:49:46] lisa d: saw some interesting suggestions in the ietf list thread, but big question is dealing with explosion of address space, proposals to deal with that are welcome [20:50:11] I think that was BoF proposals that Lisa meant [20:52:28] th: have been pushing to get in position to use vbr, would like to use it [20:53:02] falk joins the room [20:53:56] paul h: 3 or 4 entities wanting to be sources of reputation, fewer than before, none using vbr now, not clear what they mean by reputation [20:54:15] asullivan joins the room [20:54:24] So if I understand the remarks of Paul and Dave correctly, we basically just have to throw up our hands because even though there's a problem out there, what we would likely produce won't get used [20:54:35] paul h: expect to see vbr used in closed communities, eg federations [20:54:43] Klaas Wierenga leaves the room [20:54:43] This seems right to me in one sense, but it's kinda depressing, no? [20:55:39] bl: yeah, depressing [20:56:25] lucy lynch: maybe this is more of an IAB problem, more of a general architecture issue re reputation rather than case by case [20:57:19] davec: depression is misplaced, would be worse if there were a press to standardize stuff before we understand it [20:58:11] andrew s: so does this imply research agenda? [20:59:10] dave c: socializing and organizing is not same as experimentation, reputation discussions usually a mess [21:00:02] Barry Leiba leaves the room [21:00:06] falk leaves the room [21:01:24] lellel leaves the room [21:01:29] asullivan leaves the room [21:01:36] lisa d: kucherawy sender-auth is in LC, please comment [21:02:01] Yes, there are problems with this draft. [21:02:06] bl: should ASRG do market research on stds? [21:02:19] PHB leaves the room [21:02:30] aaron: no, soliciting ideas and proposals yes [21:03:02] David Cooper leaves the room [21:03:29] fenton leaves the room [21:03:41] eric leaves the room [21:03:42] sm-msk has set the subject to: Meeting ended [21:03:52] Doug Otis leaves the room [21:03:58] rlbob leaves the room [21:04:02] sm-msk leaves the room [21:04:24] sm leaves the room [21:04:32] kivinen leaves the room [21:04:35] prussell-nd leaves the room [21:06:19] ehsiegel leaves the room [21:06:55] huguei leaves the room [21:08:18] eronenp leaves the room [21:09:15] Andrew Sullivan leaves the room [21:17:24] semery joins the room [21:19:59] semery leaves the room: Replaced by new connection [21:19:59] semery joins the room [21:26:05] john.levine leaves the room [21:26:40] sftcd leaves the room: Replaced by new connection [21:26:41] sftcd joins the room [21:31:27] semery leaves the room [21:32:37] Dave Winter leaves the room [21:32:44] ESiegel joins the room [21:32:49] ESiegel leaves the room [22:01:13] Klaas Wierenga joins the room [22:01:42] Klaas Wierenga leaves the room [23:55:22] fujiwara leaves the room