[07:46:59] stefan.santesson@jabber.dk joins the room [07:47:51] stefan.santesson@jabber.dk leaves the room [12:12:25] hsantos joins the room [12:12:29] hsantos leaves the room [13:43:15] hsantos joins the room [13:43:19] hsantos leaves the room [15:48:32] dcrocker joins the room [15:50:09] fenton joins the room [15:50:27] fenton has set the subject to: DKIM WG at IETF 74 [15:57:55] semery joins the room [15:58:47] sm joins the room [15:59:09] prussell@nd,edu joins the room [15:59:15] mrex joins the room [16:00:24] eliot.lear joins the room [16:00:35] greetings [16:00:53] Melinda joins the room [16:01:41] Chairs are looking for scribes [16:01:48] bruce joins the room [16:01:55] fujiwara joins the room [16:01:57] franck.martin@jabber.org joins the room [16:02:04] i'm not getting any streaming content yet [16:02:16] Did you try webex? [16:02:22] doh! [16:02:30] David Cooper joins the room [16:02:31] still casting around for various roles. [16:02:39] I'ma als eagerly waiting for the audio stream [16:02:52] We're on WebEx as well, yes [16:03:14] https://workgreen.webex.com/workgreen/j.php?ED=108103882&UID=1056672507&PW=73ef359be60800070b&RT=MiM0 [https://workgreen.webex.com/workgreen/j.php?ED=108103882&UID=1056672507&PW=73ef359be60800070b&RT=MiM0] [16:03:26] password "dkim" [16:03:26] jtrentadams joins the room [16:03:40] is the IETF audio stream down? [16:03:51] we aren't saying much right now, though... [16:03:52] Let me see [16:04:15] rlbob joins the room [16:04:25] I can hear audio now [16:04:26] pee000 joins the room [16:04:40] dan.hoopyfrood@gmail.com joins the room [16:04:47] the new audio streaming seems to have a hang-over every morning [16:05:04] much like some WG co-chairs [16:05:39] John Schnizlein joins the room [16:05:47] Audio stream is working [16:05:51] markkao joins the room [16:06:07] sftcd joins the room [16:07:39] sm: thanks [16:08:25] I've been doing jabbber&Audio-streams for several years -- that's been working fine (in the IETF security area, at least) -- many thanks to the local participants [16:10:02] jcossio joins the room [16:10:03] just went through draft-ietf-dkim-overview, now draft-ietf-dkim-deployment [16:11:14] jdfalk joins the room [16:11:21] joncallas joins the room [16:11:30] slide dkim d, d&o [16:12:01] Ned Freed joins the room [16:12:05] ESiegel joins the room [16:12:51] is the presentation up on the IETF datatracker yet? [16:13:04] no yet, shortly [16:14:01] there are no slides for this part [16:14:54] Doug Otis joins the room [16:15:04] Doug Otis leaves the room [16:15:30] Doug Otis joins the room [16:16:13] Doug Otis leaves the room [16:21:06] john.levine joins the room [16:27:58] jim fenton is making the point that there can be other outputs as well as an identifier [16:28:38] dave crocker is making the point that all the documents we've produced (incl. 4871) do say that the output is an identifier [16:33:31] Doug Otis joins the room [16:34:13] klaas@im.wierenga.net joins the room [16:36:03] prussell@nd,edu leaves the room [16:36:22] prussell@nd,edu joins the room [16:36:47] the hubbub about i= vs. d= wasn't caused by ADSP, but rather by concerns about which identifier will be used in reputation [16:36:53] right [16:37:00] can someone pass that along to the room? [16:37:06] will do [16:37:11] thanks [16:38:50] tonyhansen joins the room [16:38:58] mic: [16:40:04] pk joins the room [16:40:15] Question: where is the signing domain opaque then? [16:40:24] s/where/why/ [16:40:34] people keep claiming interoperability concerns. The problem is that we are fighting bad guys and attempting not to be gamed. Attempt to limit flexibility and either we will get gamed, or we will be ignored. So this is a +1 to what mike thomas said. [16:41:06] eliot: was all that for the mic? [16:41:25] The more options you offer, the more opportunities bad guys have to game you. [16:41:30] (for mic if Eliot's was) [16:41:52] yes, please [16:41:58] will do [16:42:03] john- i think that's unproven. [16:42:13] but perhaps you can clue me in? [16:42:29] the most obvious example is l= which introduces new attacks [16:42:58] this is what I meant about blacklist vs. whitelist thinking [16:42:58] it is likely to be an arm race [16:43:07] franck: right [16:43:12] the signing domain is opaque in the sense that we can't add semantic value to the components. I.e., I can call my signing domain pristine.mydomain.com and then send all spam email... treating the domain component "pristine" as opaque means that we won't second-guess the categorization, that we'll just rely on the actual traffic to establish its reputation [16:43:13] i would agree with john to this extent: [16:43:25] simpler is generally better [16:43:37] klaas@im.wierenga.net leaves the room [16:43:37] but we need to stop short of telling implementations how to evaluate veracity [16:43:51] hsantos joins the room [16:44:03] Ellen, then who is claiming responsibility? BTW, I understand your point [16:45:10] the d= value is claiming responsibility. the point about opacity just means that we need to use actual experience rather than our semantic interpretaiton of the domain name components to determine what reputation to assign to that mail stream / signing entity [16:45:30] May be the specs needs to be left simple and open till experience is gained by large deployment, and then allow to review and tighten [16:45:33] IMO, reputation will require d= first and i= second if it exists. It might be replaced by r= for that matter. There does not seem to be a good reason to change RFC 4871 in that respect. A BCP seems like a better place for that type of information. [16:45:58] I agree with otis. [16:46:22] lynch joins the room [16:46:54] Michael Adkins joins the room [16:48:17] large ESP doing reputation, will not tell their formula but can be guided by BCP, but open projects like spamassassin need guidance (via BCP) [16:48:48] Interesting point Franck. [16:48:56] but ellen, that's not what "opaque" means [16:49:00] Doug Otis leaves the room [16:49:21] seems like the people most scared of choosing the wrong identifier are on the sending/signing side, not the verification & assessment side [16:49:39] jd, that's a very good point [16:49:44] someone should say that at the mic [16:49:51] yes please [16:50:31] large ESP are already doing a good reputation verification, it is for home companies running their little MTA, but DKIM needs large ESP to gain implementation [16:50:31] have they ever tried querying an ip dnsbl with the from address? [16:50:45] jd, 'scared of choosing the wrong identifier'? pls clarify [16:51:14] Michael, DKIM does not say anything about the From: address. [16:51:48] sm, i thought you had to sign it [16:51:54] they want to know which identifier their reputation will be associated with [16:51:58] Yes, you sign it (MUST) [16:51:59] was there something for me to say at the mic? [16:52:08] and jd, that's gaming. [16:52:12] nah, the conversation has moved past it [16:52:29] jdfalk: ok [16:52:34] You have to sign the From: line, but that doesn't make any promises beyond saying that the From: line in the verified message is the same one that was signed, not that it's "real". [16:52:51] that's not what I was saying :) [16:53:14] eliot: sometimes it's gaming, and sometimes they're sending for multiple clients and want to ensure that each client's reputation is distinct. whether assessors will let them get away with that is a separate question.... [16:53:50] john, Section 5.4 first sentence (rfc4871) [16:54:22] jd: agreed [16:54:35] from the receiver's perspective, jd, that's secret sauce (IMHO). [16:54:54] 5.4 says you have to sign the From: line -- but it doesn't say that you are only supposed to sign From: lines that you you know to be the true name of the sender [16:55:07] i agree [16:55:12] (john) [16:55:19] couldn't tell whether doug is in favor of the errata, or against it -- though it sounded like his points were in favor of it [16:55:36] JD: this point of single output did not originate with any sender. The point is to remove ambiguity, not to game the system. It's hard, or at least harder, to game the system if there's no ambiguity and if reputation is determined by the behavior of the mail stream. [16:55:38] i'm not sure, jd, that's the discussion [16:56:48] to dave, jim's point is when you differentiate you actually create interoperablity risks [16:56:52] well...assessors will assess whatever data we can derive (or surmise) [16:57:08] Doug Otis joins the room [16:57:26] Doug, are you in favor of the errata? [16:57:29] +1 to dave's point about separating the various sorts of crap [16:57:52] it's not a collaborative exchange!!!! [16:58:17] the receiver has to consider the sender hostile until proven otherwise [16:58:31] and the receiver gets to decide what proof it wants to use [16:58:36] +1 to Dave's point, it's an identifier [16:58:45] and once proven otherwise, how would you describe the exchange? [16:59:01] it's not EVEN an exchange [16:59:29] how would you characterize the process then? [16:59:38] an evaulation, mike [16:59:44] sm: The use of the terms opaque is troubling and does not belong in the errata. [16:59:50] although i would spell it correctly ;-) [17:01:33] I think Dave is referring to the use case of a signer collaborating with an assessor [17:01:41] as being the 'main' use case [17:01:50] which is why he likes to characterize it in those terms [17:01:54] but do you believe that? [17:01:55] The d= value is more than just an identifier, it also potentially relates to domains within signed headers. [17:02:51] who is this? [17:02:58] murray? [17:03:05] No [17:03:08] mike? [17:03:09] Mike [17:03:13] ok [17:03:20] lol [17:03:34] no one's using it yet.... [17:03:52] because they can't figure out how to [17:03:56] MIC: please say who you are, we don't all recognize your voice [17:04:22] elliot, I think the main use case will be positive reputation [17:04:40] 'main' as defined as impacting the largest amount of mail [17:04:51] jd, it might be worth hashing a bit on your sender (vs. receiver) distinction. There are all sorts of different people and different perspectives participating in each view. However I think that the basis for the rough consensus was developed primarily among people who are deeply involved in fighting spam and the bulk of those against was not. [17:05:00] senders will try to collaborate with us whether we want or need them to or not :) [17:05:00] sm leaves the room [17:05:32] sm joins the room [17:05:53] so, I mostly agree with Dave's assessment of the main use, but I disagree on the specifics of the use model [17:05:57] who is speaking? [17:06:06] guys, we *already* have senders participating in the errata. pls get the f off sender slamming. they get all of that they need at maawg... [17:06:07] that's still mike, i think [17:06:16] yeah, michael. [17:06:28] spam from bad people is zombie based, if dkim can stop that, this would be great [17:06:32] barry offered the following possible statement for the erratum draft as a way to resolve the issue: The verifier MUST supply the signing domain to the assessor. The assessor MAY use other information, including information included in the DKIM signature header field, in making its assessment. [17:06:33] michael who? [17:06:41] other will want to behave with the recipient [17:06:41] mike thomas [17:06:45] dave, you're missing my point- it's not the nice senders i'm worried about [17:06:50] and those are the ones who show up at MAAWG [17:07:05] sm-msk joins the room [17:07:11] aha [17:07:49] scrolling back a bit...I'm not saying the folks at the sender/signer end of the transaction should be ignored or discounted, but rather clarifying that the loudest demands for d=/i= clarification aren't coming from assessors [17:07:58] stupid smilies [17:08:02] d= / i= [17:08:23] right. [17:08:46] eronenp joins the room [17:09:26] Make it be a semicolon if you want a single sentence. (I'm smiling as I say it, but I'm serious.) [17:09:53] Doug's only taking about things that matter if there is an ADSP record for the domain [17:12:55] Dave says "permitting a person, role or organization that owns the signing domain to claim responsibility" in the errata " [17:13:33] Am I the only one that have a problem with the term "Responsibility?" [17:14:26] jd, my point is stronger than yours. the loudest demands (esp. for vagueness) are coming from folks not living in the world with the problem DKIM is trying to help solve. [17:14:29] i don't have a problem with it [17:14:35] with that word [17:14:44] dave: good point. [17:15:16] John Schnizlein leaves the room [17:15:20] Hector, responsible for relaying the message. [17:15:54] resnick joins the room [17:16:11] hmm, the entity who signs is claiming responsibilty. No? [17:16:41] responsible for signing it:) [17:17:49] this is such a wide-ranging conversation...what happened to the errata? [17:18:08] who is this? [17:18:11] tony hansen [17:18:14] tony hansen [17:18:15] thanks [17:20:25] The i= value may match with an email-address within a signed header, or may not match in which case it should not be considered real. This is not accurately described as always being opaque. [17:20:38] right, verifiers simply can't assume that i= is a user -- or anything else -- unless there's an out-of-band communication of some sort [17:20:52] I'm sure that "not real" is not the term we want;-) [17:21:32] but 4871 doesn't say anything about interpreting i=, so i'm not sure that's an important point right now [17:22:59] it's verified that it was signed by that domain. that's all. the trust assessment is separate. [17:23:29] yeah, it's unchanged from signing to verifying [17:23:36] that's all you can say [17:25:03] But there is a BASE ACCESSOR - the 1st domain signing domain. [17:25:34] huh? [17:26:05] Is this dave talking? [17:26:08] yeah [17:26:10] yes [17:28:04] dan.hoopyfrood@gmail.com leaves the room [17:28:09] resnick leaves the room [17:28:37] ellen siegel speaking [17:28:48] resnick joins the room [17:30:04] I agree with Ellen's point. [17:30:08] how many assessors are involved in this conversation? [17:30:34] I think we have a base accessor which is the original domain that needs to be taking into account. Doesn't the original author domain have control anymore? [17:30:53] this is tony again? [17:30:58] doug now [18:02:16] sftcd joins the room [18:02:24] jabber back [18:03:29] fenton joins the room [18:03:41] ESiegel joins the room [18:04:24] lellel joins the room [18:06:28] markkao joins the room [18:06:43] markkao leaves the room [18:07:09] Exodus joins the room [18:07:18] Exodus leaves the room [18:07:48] markkao joins the room [18:13:04] hsantos joins the room [18:13:07] lellel joins the room [18:13:46] prussell@nd,edu joins the room [18:14:06] fenton joins the room [18:14:33] hsantos leaves the room [18:14:34] hsantos joins the room [18:14:39] ESiegel joins the room [18:15:45] ?? [18:16:30] Franck Martin joins the room [18:20:29] lellel leaves the room [18:30:37] markkao leaves the room [18:30:44] prussell@nd,edu leaves the room [18:32:05] hsantos leaves the room [18:32:11] john.levine joins the room [18:32:43] hector joins the room [18:32:46] fenton leaves the room [18:33:00] jdfalk joins the room [18:33:16] hector leaves the room [18:33:18] ha, NOW I can get back into this chat [18:33:27] jdfalk leaves the room [18:33:40] jtrentadams joins the room [18:34:23] eliot.lear joins the room [18:34:49] karen.s.seo joins the room [18:35:34] bruce joins the room [18:35:37] karen.s.seo leaves the room [18:35:47] pee000 joins the room [18:37:25] pee000 leaves the room [18:40:23] pk joins the room [18:40:57] jtrentadams leaves the room [18:41:03] Franck Martin leaves the room [18:44:37] bruce leaves the room [18:50:25] ESiegel leaves the room [18:55:27] Franck Martin joins the room [18:56:12] jtrentadams joins the room [18:56:17] john.levine leaves the room [18:57:13] jtrentadams leaves the room [18:59:31] john.levine joins the room [18:59:35] hsantos joins the room [19:04:27] I just connected to the audio server and I'm getting an IPR session [19:04:29] is DKIM over? [19:06:09] Barry Leiba joins the room [19:06:45] are other people getting DKIM audio? [19:06:47] DKIM working group meeting, 25 March 2009 This is the content of the WebEx chat, which was used when there were problems with the jabber room. 03/25/2009 10:09:25 AM from Jim Fenton: Note that I have remotely muted some people -- you may need to unmute yourself to speak 03/25/2009 10:09:34 AM from Dennis Dayman: thx 03/25/2009 10:10:54 AM from Dennis Dayman: is that someone in teh audience speaking? 03/25/2009 10:10:58 AM from Jim Fenton: ok then nudge me here or on Jabber 03/25/2009 10:10:59 AM from Jon Callas: could the speakerget closer to the mic? 03/25/2009 10:11:08 AM from Jon Callas: what's the jabber room? 03/25/2009 10:11:37 AM from Jim Fenton: jabber room is dkim@jabber.ietf.org 03/25/2009 10:12:25 AM from J.D. Falk: is there a better audio stream, or is webex it? 03/25/2009 10:12:56 AM from Jon Callas: Yes, can we get a mic to the speaker? 03/25/2009 10:13:49 AM from Dave Crocker: there is a conference audio stream from the ietf: 03/25/2009 10:14:54 AM from J.D. Falk: webex audio is working now (though it's kinda amusing to listen to both at once) 03/25/2009 10:23:15 AM from J.D. Falk: can barely hear Dave 03/25/2009 10:24:21 AM from Dennis Dayman: audio is great using the stream from IETF website 03/25/2009 10:24:48 AM from J.D. Falk: thanks, I'll switch over -- though I noticed it's a few seconds delayed 03/25/2009 10:30:46 AM from Dave Crocker: "can barely hear Dave " - wow. I don't get that very often. 03/25/2009 10:31:42 AM from J.D. Falk: Dennis was right: this 64k mp3 stream sounds way better than the overcompressed audio from webex 03/25/2009 10:32:21 AM from Hector Santos: The IETF audo stream is great! 03/25/2009 10:32:33 AM from Jon Callas: where is it? 03/25/2009 10:32:50 AM from J.D. Falk: http://feed.verilan.com:8000/imperial_a 03/25/2009 10:33:14 AM from Hector Santos: Jon, http://feed.verilan.com:8000/imperial_a.m3u 03/25/2009 10:33:53 AM from Michael Adkins: I'm guessing that we'll still need to stay on the phone if we want to talk, right? 03/25/2009 10:34:11 AM from Jim Fenton: right, or we can channel you if you type here or on the jabber room 03/25/2009 10:35:33 AM from Hector Santos: Love to know who is currently speaking. 03/25/2009 10:35:50 AM from Jim Fenton: this is barry 03/25/2009 10:37:00 AM from Michael Hammer: I think Hector means who is speaking voice 03/25/2009 10:38:02 AM from Michael Hammer: +1 to what Ellen is saying 03/25/2009 10:39:21 AM from Michael Adkins: d= is the required one 03/25/2009 10:40:40 AM from Hector Santos: I agree too. 03/25/2009 10:41:30 AM from Michael Hammer: How does one identify a spoofed message from DKIM base? 03/25/2009 10:42:05 AM from Hector Santos: I agree. 03/25/2009 10:42:43 AM from Hector Santos: who is speaking? 03/25/2009 10:43:07 AM from Michael Adkins: Murray K 03/25/2009 10:44:26 AM from J.D. Falk: some good side conversation on the jabber, BTW 03/25/2009 10:44:43 AM from Michael Adkins: dkim@jabber.ietf.org? 03/25/2009 10:44:44 AM from Michael Hammer: My pidgin client keeps on blowing up when I try to join the room 03/25/2009 10:44:56 AM from J.D. Falk: madkins: yep 03/25/2009 10:45:18 AM from J.D. Falk: works fine in iChat... *shu rg* 03/25/2009 10:51:16 AM from Hector Santos: Is that not determine by the DOMAIN signer? 03/25/2009 10:51:51 AM from Hector Santos: The signer should have the alternate say what a verifier should do. 03/25/2009 10:52:09 AM from Hector Santos: as far was what is bad. 03/25/2009 10:52:52 AM from Hector Santos: I agree. 03/25/2009 10:56:51 AM from Hector Santos: Nodding head. 03/25/2009 11:00:01 AM from Hector Santos: Man, its amazing that Dave feels this way. He doesn't reflect these views in the WG. 03/25/2009 11:05:19 AM from Florian Sager: I agree, there is some need for a collection of demands from practical work 03/25/2009 11:05:48 AM from Florian Sager: I guess the amount of output values will turn out to be rather small. 03/25/2009 11:06:55 AM from Dennis Dayman: he's coming out of the closet? ;) 03/25/2009 11:17:41 AM from Florian Sager: don't forget there may be data (e.g. user-based-identifiers) the signer should be able to provide somehow and that can be used by an accessor if the accessor trusts the signing domain. This is abstract from DKIM itself but it seems to me it's technically reasonable to transfer this data. as part of the signature. 03/25/2009 11:18:36 AM from J.D. Falk: yep, that's the part that's best left vague for now (IMO) 03/25/2009 11:18:55 AM from Dennis Dayman: +1 03/25/2009 11:24:09 AM from Michael Hammer: The signature is only that the signing domain is taking some responsibility for that particular mail 03/25/2009 11:25:39 AM from Dennis Dayman: who is that? 03/25/2009 11:25:48 AM from Hector Santos: But there is a BASE ACCESSOR - the 1st domain signing domain. 03/25/2009 11:26:11 AM from Michael Hammer: does it matter unles we are talking about ADSP? 03/25/2009 11:34:15 AM from Ellen Siegel: what happened to the jabber room? 03/25/2009 11:34:19 AM from Hector Santos: Did the jabber room crash? 03/25/2009 11:34:33 AM from Michael Adkins: I don't think so 03/25/2009 11:34:34 AM from Eliot Lear: seems to have for me. 03/25/2009 11:34:40 AM from Hector Santos: me too. 03/25/2009 11:34:59 AM from Eliot Lear: nice to have a backup ;-) 03/25/2009 11:35:08 AM from Michael Adkins: ah, nm. it has 03/25/2009 11:35:46 AM from J.D. Falk: hm yes, perhaps it has. wacky. 03/25/2009 11:36:05 AM from Hector Santos: I just created: dkim@conference.jabber.isdg.net 03/25/2009 11:38:12 AM from Eliot Lear: MIC: are these architectural components or functions of the same component? 03/25/2009 11:38:30 AM from Eliot Lear: do we have verification and assessement or verifier and assessor? 03/25/2009 11:39:08 AM from Michael Adkins: architectural components 03/25/2009 11:39:49 AM from Dave Crocker: Barry's summary of tasks: 1) fix/replace use of 'opaque'; 2) fix definition of 'assessor'; and 3) clarify must/may statement on output to assessor 03/25/2009 11:40:00 AM from Michael Hammer: I think I agree with Mike Adkins.... architectural components gives us more flexibility down the road 03/25/2009 11:41:01 AM from Eliot Lear: the distinction is that you don't have to worry about API issues if you have functions as opposed to componentry 03/25/2009 11:41:03 AM from Hector Santos: is the jabber room open? 03/25/2009 11:41:27 AM from J.D. Falk: I'm unable to connect to either the official jabber, or your alternate 03/25/2009 11:41:30 AM from Eliot Lear: you don't have to get into MUST/ MAYs 03/25/2009 11:41:34 AM from Eliot Lear: which was jim's point 03/25/2009 11:41:42 AM from Michael Hammer: Do you feel that API issues would be that significant? 03/25/2009 11:41:49 AM from Michael Adkins: I agree with your distinction, but I believe they are implemented as architectural components in existing systems 03/25/2009 11:42:07 AM from Eliot Lear: not in all such systems 03/25/2009 11:42:10 AM from Michael Adkins: true 03/25/2009 11:42:11 AM from Jim Fenton: Yeah, it looks like there are problems with the jabber room 03/25/2009 11:42:30 AM from Michael Adkins: if you want to do both in the some component, you may 03/25/2009 11:42:36 AM from Michael Adkins: *same 03/25/2009 11:43:17 AM from Michael Adkins: but the strength of a standard identifier is that the assessment component can be maintained by another organization 03/25/2009 11:43:18 AM from J.D. Falk: Eliot, Michael: might that be the core of the confusion? 03/25/2009 11:44:00 AM from Michael Adkins: I'm not sure what the confusion is about.... I'm not sure any of the confused people are verifiers or assessors 03/25/2009 11:44:29 AM from Eliot Lear: michael, your concern is the sender. right? 03/25/2009 11:45:03 AM from Michael Hammer: which Michael? 03/25/2009 11:45:06 AM from Eliot Lear: adkins 03/25/2009 11:45:08 AM from Michael Adkins: my concern is the small verifiers that cannot perform their own assessments 03/25/2009 11:45:25 AM from Eliot Lear: why would they perform their own verification? 03/25/2009 11:45:27 AM from Michael Adkins: senders will follow suit with the major isps 03/25/2009 11:45:46 AM from Michael Adkins: verification requires access to the mail stream 03/25/2009 11:46:30 AM from Eliot Lear: so then what gets sent to the assessor? ONLY the SDID? 03/25/2009 11:46:55 AM from Michael Adkins: By default, the SDID 03/25/2009 11:47:24 AM from Michael Hammer: There might be additional information as was discussed earleir but it would be tied to SDID 03/25/2009 11:47:44 AM from Michael Adkins: if the assessor might support other input, they would have to communicate that to the verifiers 03/25/2009 11:48:02 AM from Eliot Lear: ok. so we're talking about whitelist/blacklists 03/25/2009 11:48:07 AM from Eliot Lear: as an example 03/25/2009 11:48:10 AM from Michael Hammer: or it might be an extension to DKIM 03/25/2009 11:48:24 AM from Michael Adkins: correct, that is an example 03/25/2009 11:48:50 AM from Eliot Lear: ok. i see your point. 03/25/2009 11:48:57 AM from J.D. Falk: MIC: there's a constituency who keep saying "DKIM is useless" because they don't understand it. they're confused. a long update process would add to their confusion. 03/25/2009 11:49:16 AM from Michael Hammer: or it might be something along the lines of Daves afilias proposal 03/25/2009 11:49:20 AM from J.D. Falk: (there are also a few who say it's useless because they DO understand it, and disagree, but that's different) 03/25/2009 11:49:30 AM from Michael Adkins: we're planning on using SDID for internal assessment by default 03/25/2009 11:49:44 AM from Michael Adkins: and then considering additional information for certain types of domains 03/25/2009 11:49:51 AM from DKIM Chairs: OK, JD... after Tony. 03/25/2009 11:50:03 AM from J.D. Falk: thanks, chairs 03/25/2009 11:50:44 AM from Eliot Lear: in that case, isn't it up to the verifier to decide what it wants verified? 03/25/2009 11:51:38 AM from Eliot Lear: if it wants to verify the From: line domain in the context of a particular SDID, ... 03/25/2009 11:51:43 AM from J.D. Falk: +1 to moving quickly, regardless of precise process used 03/25/2009 11:51:43 AM from Michael Adkins: I don't think so. The verifier is the actor that knows the least. 03/25/2009 11:52:08 AM from Michael Adkins: the signer potentially knows useful things about it's mail 03/25/2009 11:52:14 AM from Michael Hammer: Do you mean verify Eliot or do you mean assess? 03/25/2009 11:52:28 AM from Eliot Lear: verifier 03/25/2009 11:52:58 AM from Michael Adkins: the assessor knows the results of its assessments 03/25/2009 11:53:20 AM from Michael Adkins: but the verifier really only knows the result of verification, pass or fail 03/25/2009 11:53:22 AM from Michael Hammer: I'll bite.... so how does the verifier verify the From address? 03/25/2009 11:53:43 AM from J.D. Falk: now I'm tempted to submit the peanut butter errata 03/25/2009 11:54:14 AM from Michael Adkins: if the verifier wants the assessor to provide data about a From: address, they will have to find or create an assessor that does so 03/25/2009 11:54:26 AM from Michael Adkins: and then modify their verification process to send that data as well 03/25/2009 11:54:28 AM from J.D. Falk: the verifier can't verify that the from address is true, but can verify that it was signed -- and if it was signed by someone trusted, then they can (if they wish) assume that the from is true 03/25/2009 11:54:34 AM from Eliot Lear: if the From: address is signed, (which it is), then it might want to know something more granular. 03/25/2009 11:54:41 AM from Eliot Lear: as an example 03/25/2009 11:54:51 AM from Jon Callas: (switching to phone as I have to get into the car.) 03/25/2009 11:55:12 AM from Eliot Lear: the verifier might trust the assessor on both counts. 03/25/2009 11:55:22 AM from Michael Adkins: I agree 03/25/2009 11:55:33 AM from J.D. Falk: thanks for squeezing my comment in there 03/25/2009 11:55:37 AM from Michael Adkins: in which case it could send both the SDID and From to the assessor 03/25/2009 11:55:42 AM from DKIM Chairs: We try. 03/25/2009 11:55:48 AM from Michael Adkins: I don't think the errata forbids that 03/25/2009 11:55:58 AM from Michael Hammer: I don't think it does either 03/25/2009 11:55:59 AM from Michael Adkins: it just makes it an extension from the default 03/25/2009 11:56:16 AM from Michael Hammer: But I'm not sure I would consider that verifying.... I would call it assessing 03/25/2009 11:56:27 AM from Michael Hammer: as in, "What do these signed things mean" 03/25/2009 11:56:33 AM from Eliot Lear: all i'm getting to is jim's point about what is passed between the two. 03/25/2009 11:57:04 AM from Michael Adkins: sure 03/25/2009 11:57:04 AM from Eliot Lear: maybe in my example, the one guy is both verifier and assessor 03/25/2009 11:57:10 AM from Michael Adkins: possibly 03/25/2009 11:57:15 AM from Michael Adkins: internally here, I'm both 03/25/2009 11:57:21 AM from Eliot Lear: right 03/25/2009 11:57:22 AM from Michael Adkins: so I tend to see things in that light as well 03/25/2009 11:58:33 AM from Michael Hammer: I'm just thinking out loud, but on the inbound side I might rely on postini to validate but do additional assessment once it gets to our systems 03/25/2009 11:58:49 AM from Michael Adkins: and I would actually say that the verifier is not the part that would want more info, the handling filter is 03/25/2009 11:58:59 AM from Michael Hammer: correct 03/25/2009 11:59:02 AM from Michael Adkins: but that's more architectural discussion 03/25/2009 11:59:35 AM from J.D. Falk: one of the cool things about DKIM (vs. IPs) is that it becomes easier to have multiple layers of assessment with access to the same identifier 03/25/2009 11:59:37 AM from Murray Kucherawy: wow. 03/25/2009 11:59:45 AM from Hector Santos: wow is right. 03/25/2009 11:59:45 AM from Michael Hammer: I think architecture is important because it helps us test the theory 03/25/2009 12:00:57 PM from Michael Hammer: louder Ellen 03/25/2009 12:02:03 PM from J.D. Falk: I find myself caring less and less about the process the longer this goes on. 03/25/2009 12:02:11 PM from Michael Adkins: +1 03/25/2009 12:02:12 PM from Eliot Lear: here's a q- what if your input to the assessor needs to be IP address and domain? what does the interface look like? 03/25/2009 12:02:37 PM from Hector Santos: I could never survive this. :-) 03/25/2009 12:02:38 PM from Michael Adkins: to a single assessor? or one for each? 03/25/2009 12:02:48 PM from Eliot Lear: to a single assessor? 03/25/2009 12:03:30 PM from Eliot Lear: and we know that happens. 03/25/2009 12:03:54 PM from Michael Adkins: how do we vote via chat? 03/25/2009 12:04:00 PM from Murray Kucherawy: will relay 03/25/2009 12:04:01 PM from Eliot Lear: just say it in the chat 03/25/2009 12:04:08 PM from Murray Kucherawy: what's your vote? 03/25/2009 12:04:10 PM from Hector Santos: I vote for to follow procedure. 03/25/2009 12:04:18 PM from Murray Kucherawy: hector: what's procedure? 03/25/2009 12:04:50 PM from sm: I'm for procedure 03/25/2009 12:04:58 PM from Murray Kucherawy: what's procedure? 03/25/2009 12:05:02 PM from Murray Kucherawy: there are two procedures at least 03/25/2009 12:05:04 PM from Murray Kucherawy: pick one 03/25/2009 12:05:07 PM from sm: IETF process ;-) 03/25/2009 12:05:19 PM from Murray Kucherawy: which one? 03/25/2009 12:05:25 PM from Michael Adkins: I'm for whatever is quickest 03/25/2009 12:05:34 PM from sm: It's the IETF Standards Process, Murray 03/25/2009 12:05:38 PM from J.D. Falk: I'm with madkins 03/25/2009 12:05:49 PM from Murray Kucherawy: ok so SM votes for I-D method 03/25/2009 12:05:53 PM from Murray Kucherawy: anyone else? 03/25/2009 12:05:58 PM from Michael Hammer: If we have a consensus on the 3 points raised earlier 03/25/2009 12:06:07 PM from Ellen Siegel: me too... more delay means additional time for confusion over the ambiguities 03/25/2009 12:06:22 PM from sm: Well, Pasi can speed it up 03/25/2009 12:06:31 PM from Murray Kucherawy: who's being harmed by that though? i think that's a legitimate question 03/25/2009 12:06:34 PM from Michael Adkins: is the jabber room back up? I can't seem to connect still. 03/25/2009 12:06:35 PM from Murray Kucherawy: is there a clear and present danger? 03/25/2009 12:06:40 PM from Murray Kucherawy: madkins: me either 03/25/2009 12:06:44 PM from Eliot Lear: me either 03/25/2009 12:06:53 PM from J.D. Falk: no jabber lovin' here 03/25/2009 12:06:56 PM from Eliot Lear: murray, that's been my question all along. 03/25/2009 12:06:59 PM from Ellen Siegel: it seems to be back up, but there's no content yet 03/25/2009 12:07:00 PM from Michael Hammer: can we publish something informational as interim but letting people know where the I-D is going 03/25/2009 12:07:02 PM from sm: Jabber is down 03/25/2009 12:07:19 PM from Michael Hammer: I prefer speed as well 03/25/2009 12:07:22 PM from Murray Kucherawy: i still can't join jabber 03/25/2009 12:07:25 PM from Hector Santos: I have someone working on a backup room. Seems t only work with local accounts. 03/25/2009 12:07:26 PM from Murray Kucherawy: mhammer: why? 03/25/2009 12:07:33 PM from Hector Santos: I'm getting it opened up now. 03/25/2009 12:07:49 PM from Michael Hammer: I prefer speed which would indicate errata approach 03/25/2009 12:07:50 PM from Hector Santos: Me too! 03/25/2009 12:08:06 PM from J.D. Falk: hammer: I think we should keep publishing clarification & discussion on circleid & such, since the current process discussions are so unwelcoming to anyone who just wants to find out WTF is going on with DKIM 03/25/2009 12:08:08 PM from Michael Hammer: On the other hand I want to find a way to get consensus 03/25/2009 12:08:08 PM from Murray Kucherawy: so you just want it done, plain and simple? 03/25/2009 12:08:25 PM from J.D. Falk: in other words, non-IETF-process clarifications while the IETF process churns on 03/25/2009 12:08:32 PM from Hector Santos: who speaking agin? 03/25/2009 12:08:37 PM from Michael Hammer: that is risky J.D. 03/25/2009 12:08:38 PM from sm: Jim 03/25/2009 12:08:39 PM from Eliot Lear: jim fenton 03/25/2009 12:08:43 PM from Ellen Siegel: was Jim, now Pasi 03/25/2009 12:08:54 PM from J.D. Falk: hammer: agreed 03/25/2009 12:09:26 PM from Michael Hammer: Murray: It's not simply that I want it done. It's that ongoing confusion is detrimental to broader implementation 03/25/2009 12:09:44 PM from Michael Hammer: I want it done "right" 03/25/2009 12:09:54 PM from Murray Kucherawy: in that sense i think getting ADSP out is more important than this; our biggest complaint in industry is that that piece keeps changing 03/25/2009 12:10:07 PM from Michael Hammer: I agree Murray 03/25/2009 12:10:37 PM from sm: i= would be better if we want to keep g= 03/25/2009 12:10:41 PM from Michael Hammer: But "this" can knock ADSP implementation off it's feet 03/25/2009 12:10:41 PM from Murray Kucherawy: but regarding the SDID/AUID stuff, i agree it hasn't been explained what the big present threat is which requires immediate processing 03/25/2009 12:11:14 PM from Murray Kucherawy: the alleged ambiguities in 4871 haven't caused any obvious harm so far, especially given the interop success 03/25/2009 12:11:54 PM from Michael Hammer: Murray: I think there is a significant difference between interop success and implementation in the wild 03/25/2009 12:12:00 PM from Murray Kucherawy: i like the approach the errata effort is taking but i haven't seen anything that makes me want to get behind "do it NOW" 03/25/2009 12:12:09 PM from Michael Adkins: eliot, an interface that has to handle multiple identifiers on a single message will have to start with answering the question of whether the assessor gets to decide which identifier gets precidence, and therefore only that result is returned, or whether 03/25/2009 12:12:18 PM from Murray Kucherawy: there may be, but have we heard any complaints to which we are responding? 03/25/2009 12:12:28 PM from Michael Adkins: whoops, I think I got truncated 03/25/2009 12:12:54 PM from sm: Question: can someone explain what g= is for? 03/25/2009 12:13:02 PM from Michael Hammer: Did you look at my post to CircleID on the message-id ehader or Marks post about validation failrue cases? 03/25/2009 12:13:12 PM from Michael Hammer: ehader = header 03/25/2009 12:13:29 PM from Michael Hammer: I need to type more carefully 03/25/2009 12:13:37 PM from DKIM Chairs: The jabber room appears to be back, so please move discussion there (it's archived). 03/25/2009 12:13:40 PM from J.D. Falk: MIC: I'm fairly certain that ADSP i= doesn't prevent other uses of i= 03/25/2009 12:13:42 PM from Murray Kucherawy: what's circleid? 03/25/2009 12:13:51 PM from sm: some website 03/25/2009 12:14:29 PM from sm: I'll send you the link, Murray 03/25/2009 12:14:35 PM from J.D. Falk: circleid.com, a multi-author blog type site focused on network stuff 03/25/2009 12:15:09 PM from sm: BTW jabber is still down 03/25/2009 12:15:14 PM from J.D. Falk: yeah, still no jabber 03/25/2009 12:15:46 PM from Paul Russell: just successfully logged in to jabber & joined conference room 03/25/2009 12:15:47 PM from Michael Hammer: It initially applies to a small number of domains 03/25/2009 12:15:49 PM from Hector Santos: Its open again from here JD 03/25/2009 12:16:05 PM from Michael Hammer: I think over time more domains will move in that direction 03/25/2009 12:16:05 PM from Eliot Lear: steve, you can say that we have to worry about precedence, but that is what some people do with very valid reasons 03/25/2009 12:16:12 PM from J.D. Falk: dkim@jabber.ietf.org, right? 03/25/2009 12:16:19 PM from sm: Yes 03/25/2009 12:16:25 PM from sm: Still not working for me 03/25/2009 12:16:50 PM from sm: Can someone ask my question about what g= is for? 03/25/2009 12:16:52 PM from Murray Kucherawy: still not working for me either 03/25/2009 12:18:43 PM from Michael Hammer: There is another value to using i=, which is that a single signing key can be used for multiple subdomains (that are used in i=) 03/25/2009 12:18:50 PM from Jim Fenton: g= (which was in DomainKeys as well) is intended to allow a domain owner to delegate a key to a party they don't fully trust 03/25/2009 12:19:18 PM from sm: Jim, what's the user if we are going for domains only? 03/25/2009 12:19:26 PM from sm: I mean what's the use 03/25/2009 12:19:43 PM from Michael Hammer: If you trust em some but not enough then delegate a subdomain and let them gen their own signing key 03/25/2009 12:20:02 PM from Michael Hammer: but if you really only trust them some, why give them a key at all? 03/25/2009 12:20:05 PM from sm: Mike, it's not subdomain. There are also constraints on the local-part 03/25/2009 12:20:17 PM from sm: I mean Michael 03/25/2009 12:20:19 PM from John Levine: Re Jim's point, this is the issue of asking recipients to do your user management 03/25/2009 12:20:54 PM from Michael Hammer: We delegate our newsletter mailings to ExactTarget... we give them a seperate subdomain 03/25/2009 12:21:11 PM from Michael Hammer: So let them send from whatever user at that subdomaint hey want 03/25/2009 12:21:23 PM to Dave Crocker: I think we'll see a nearly infinite number of different experiments for dealing with delegation 03/25/2009 12:21:26 PM from Michael Hammer: If we have a problem we change DNS 03/25/2009 12:21:49 PM from J.D. Falk: I think we'll see a nearly infinite number of different experiments for dealing with delegation 03/25/2009 12:22:01 PM from Michael Hammer: +1 03/25/2009 12:24:01 PM from Michael Hammer: If I might digress a second.... for ADSP, what would be people think of a tag along the lines of ADSP=Y if someone is publishing ADSP records? 03/25/2009 12:24:14 PM from Murray Kucherawy: interesting 03/25/2009 12:24:24 PM from Michael Hammer: That would save a lot of DNS lookups 03/25/2009 12:24:29 PM from Michael Adkins: how? 03/25/2009 12:24:33 PM from DKIM Chairs: But you only look for ADSP records if you don't have an author-domain sig. 03/25/2009 12:24:41 PM from DKIM Chairs: So how would such a tag work? 03/25/2009 12:24:43 PM from Jim Fenton: The tag doesn't help if there's no signature at all 03/25/2009 12:24:51 PM from Michael Hammer: Sure it does in a round about way 03/25/2009 12:25:13 PM from Michael Hammer: If I'm sending you messages every day all day long that have ADSP=Y 03/25/2009 12:25:29 PM from Paul Russell: if there is no sig, there cannot possibly be a tag that would be a component of the sig 03/25/2009 12:25:33 PM from Michael Hammer: I'm assuming you are going to pay attention to that 03/25/2009 12:25:48 PM from Michael Hammer: that is, you will be building a list of domains that sign 03/25/2009 12:25:58 PM from Michael Hammer: "all" or "discardable" 03/25/2009 12:26:13 PM from Michael Adkins: I can do that with or without an ADSP tag 03/25/2009 12:26:44 PM from Michael Hammer: Jsut trying to address the complaint that initially there will be a low number of domains publishing ADSP 03/25/2009 12:26:53 PM from J.D. Falk: can the slides be on webex? 03/25/2009 12:27:08 PM from Michael Hammer: and thinking along the lines of hints 03/25/2009 12:28:20 PM from Ellen Siegel: mike (adkins): what's your take on r=? 03/25/2009 12:28:22 PM from DKIM Chairs: Slides are on Webex now. 03/25/2009 12:28:59 PM from J.D. Falk: thanks, chairs 03/25/2009 12:29:14 PM from Michael Adkins: my take is that I would use it the way I currently intend to use i= 03/25/2009 12:29:49 PM from Michael Adkins: I'll only care for certain domains 03/25/2009 12:29:59 PM from J.D. Falk: I'd agree (wearing my assessor hat) 03/25/2009 12:30:57 PM from Michael Adkins: I don't really see why it's needed though 03/25/2009 12:31:04 PM from J.D. Falk: primary concern would be that adding this tag before everyone in the industry understands that the d= / i= debate is settled will just make the debate louder 03/25/2009 12:31:14 PM from Michael Adkins: +1 [19:06:51] I'm getting an IPR session [19:07:01] eliot.lear leaves the room [19:07:21] The DKIM meeting is long over, John. [19:07:36] Ended almost 40 minutes ago. [19:07:46] oh, right, we're not on daylight time yet [19:07:47] never mind [19:09:12] Barry Leiba leaves the room [19:17:30] hsantos leaves the room [19:19:01] hsantos joins the room [19:19:28] did someone forget to turn off the mike? :-) [19:20:04] hsantos leaves the room [19:22:18] John Schnizlein joins the room [19:22:41] hsantos joins the room [19:22:43] hsantos leaves the room [19:22:46] John Schnizlein leaves the room [19:23:22] bruce joins the room [19:24:16] bruce leaves the room [19:43:02] Franck Martin leaves the room [19:51:26] pk leaves the room: Computer went to sleep [20:21:13] ESiegel joins the room [20:21:15] ESiegel leaves the room [20:53:41] Franck Martin joins the room [21:21:48] john.levine leaves the room [21:59:46] Franck Martin leaves the room [22:50:45] Franck Martin joins the room