[00:04:10] --- earl has left: Disconnected
[00:33:20] --- zerosixty has left: Replaced by new connection
[00:58:19] --- zerosixty has become available
[01:07:48] --- dcrocker has become available
[01:08:30] <dcrocker> 2.5 hours until the MASS BOF
[01:08:43] * dcrocker has changed the subject to: Baited Breath: MASS BOF
[01:14:39] --- zerosixty has left: Replaced by new connection
[01:20:54] --- dcrocker has left: Replaced by new connection
[01:20:55] --- dcrocker has become available
[01:27:53] --- dcrocker has left
[01:54:36] --- fanf has become available
[03:06:26] --- jlcjohn has become available
[03:13:51] --- anewton has become available
[03:15:14] --- dcrocker has become available
[03:20:15] --- fanf has left: Replaced by new connection
[03:20:15] --- fanf has become available
[03:20:28] --- fanf has left
[03:20:47] --- fanf has become available
[03:21:46] --- Hollenbeck has become available
[03:23:41] --- leifj has become available
[03:24:57] --- fenton has become available
[03:26:01] --- warlord has become available
[03:26:07] --- tonyhansen has become available
[03:26:26] --- raeburn has become available
[03:26:53] --- mass has become available
[03:27:26] --- cnewman has become available
[03:27:37] <tonyhansen> time for deep breathing exercises everyone :-)
[03:27:51] <warlord> Shall we start in Latin?
[03:28:01] <tonyhansen> ommmmm
[03:28:36] --- paulmdx has become available
[03:28:37] --- pigdog has become available
[03:28:38] --- Barry Leiba has become available
[03:28:39] <fenton> No, en Francais
[03:28:40] <cnewman> Piea easu dominau... Thunk... Domias requim... Thunk...
[03:29:15] <pigdog> good morning/afternoon/evening. this is the MASS BOF. Dave Crocker and Jim Fenton are chairing and I will be jabbering.
[03:29:41] --- dcrocker has left
[03:29:45] --- eric has become available
[03:29:47] <Barry Leiba> You don't frighten us, English pigdogs!
[03:30:05] --- robertml has become available
[03:30:11] --- arvel has become available
[03:30:13] <pigdog> if you have a question/comment for the working group, please write "COMMENT" at the beginning and I will speak your words into the microphone.
[03:30:41] <Barry Leiba> Qui est "pigdog", anyway?
[03:30:46] --- milele has become available
[03:30:46] <pigdog> eliot lear
[03:31:37] <pigdog> Dave has called the meeting to order.
[03:31:38] --- hartmans has become available
[03:31:38] --- marcos has become available
[03:32:19] --- shima has become available
[03:32:22] <pigdog> there is now dkim.org.
[03:32:25] <pigdog> agenda.
[03:32:27] --- hardie@jabber.psg.com has become available
[03:32:37] <pigdog> AD greeting
[03:32:40] <pigdog> agenda bashing
[03:32:42] <pigdog> dkim review
[03:32:43] <pigdog> ipr
[03:32:44] <pigdog> charter
[03:32:56] <pigdog> Russ Housley:
[03:33:40] <pigdog> "about five or six IETFs ago we had a thing called a MASS bof and I think we listened to seven proposals. A whole bunch of work has been done since that time. Several proposals have been merged to create DKIM, which is what we are here to talk about."
[03:34:16] <pigdog> "Calling this a MASS BoF was a mistake..."
[03:34:28] <pigdog> "DKIM is the first technology to advance to have a BOF".
[03:34:41] <tonyhansen> ? for Dave: are the slides available anywhere?
[03:34:58] <pigdog> "The first technology that gets a WG will raise the bar for others for interoperability's sake."
[03:35:14] <pigdog> "is this the one we want to raise the bar?"
[03:35:27] <fanf> th: the slides are linked from dkim.org
[03:35:34] --- admcd has become available
[03:35:39] <wrs1864> dave: yes, there is at least one person awake in the US and listening on the audio feed...
[03:35:43] <pigdog> dave: yes, slides are on dkim.org
[03:35:57] --- rbless has become available
[03:35:58] --- dblacka has become available
[03:36:13] <pigdog> there is also a threat analysis that was produced over the last three days by Eric, John Callas, and others. everything is on http://dkim.org
[03:36:58] <pigdog> agenda bashing
[03:37:04] --- hallam has become available
[03:37:15] <pigdog> EKR: so we're not going to see a threat analysis before we describe the protocol?
[03:37:52] <pigdog> Jim Fenton: there was some in the DKIM draft, but the threat-analysis draft is too fresh
[03:38:07] <pigdog> other agenda bashing?
[03:38:14] <pigdog> moving right along...
[03:38:18] --- james has become available
[03:38:21] <pigdog> DKIM review
[03:38:30] <pigdog> Eric Allman presenting
[03:38:44] --- pguenther has become available
[03:38:50] <pigdog> There is nothing in this presentation that is not in the draft posted 3 weeks ago
[03:38:55] <wrs1864> this would be the DKIM-teaser.pdf?
[03:38:56] <pigdog> Several goals
[03:39:13] <pigdog> 0th goal: deployable
[03:39:45] <pigdog> low cost. Didn't want to have to put up new internet services. We didnt' want trusted third parties because they're often not trusted.
[03:39:55] <pigdog> we did not want to require client user upgrades.
[03:40:09] <pigdog> too large installed base
[03:40:33] <pigdog> naive users get scared when they see new things pop up. So we wanted to keep that to a minimum.
[03:40:53] <wrs1864> I think the slides are the intro-EAIS-NYC.pdf slides
[03:41:00] <pigdog> as a correlary, we are thinking what can be used as input to other algorithms. authenticated identity for purposes of reputation.
[03:41:11] <pigdog> we do validate the message itself rather than just the path.
[03:41:26] <pigdog> distinguishing this from, say sender-id.
[03:41:54] <pigdog> you need to be able to delegate permission to use an address or group of addresses to a 3rd party but you don't want them to masquerade as the ceo of your company.
[03:42:09] <pigdog> we do want extensibility because we know the world changes.
[03:42:26] <hardie@jabber.psg.com> Can the sender delegation work without updated UAs?
[03:42:46] <pigdog> as to what kind of key services you use, the base document says DNS. we didn't want to require a new PKI. SHA-1 is good enough but could be extended.
[03:43:13] <pigdog> we wanted a structure to permit per-user signing. we are aware that doing per user keys in DNS is a horrid mistake.
[03:43:18] <paulmdx> hardie - depends how good the outgoing MTA is?
[03:43:30] <fenton> hardie: delegation doesn't depend on the UA at all.
[03:43:35] <pigdog> [ted- let me know when you want me to put you in a queue with a question.]
[03:43:50] <pigdog> use COMMENT to do that
[03:44:09] <pigdog> this is not just a yahoo cisco proposal,.. other orgs involved including Sendmail.
[03:44:16] <hardie@jabber.psg.com> pigdog: I'm in the room, so if I want to ask at the mic, I will.
[03:44:18] <pigdog> it looks a lot like domain keys.
[03:44:21] <hardie@jabber.psg.com> thanks
[03:44:52] <pigdog> looks like like DK, that's intentional. new header name.
[03:44:53] <hallam> ted - the type of delegation they are referring to is to allow constant contact to send out a bulk mail run on their behalf. it is considered acceptable for this to involve DNS configuration.
[03:45:04] <pigdog> dkim signature is self signed
[03:45:28] <hartmans> Ted, I think the issue is that the UA does not need to be the verifier.
[03:45:35] <hardie@jabber.psg.com> fenton: okay, but if you push past that you seem to hit per-user keys? That is, this works for outsourcing, but for forwarding you use re-injection?
[03:45:36] <pigdog> storing public keys in DNS. use new RR type. we will fall back to txt records until rr can get deployed.
[03:45:52] <pigdog> dkim is backward compatable with DK.
[03:45:58] <hartmans> So, the signer and verifier need upgrades, but the UA does not
[03:46:03] <pigdog> single domain can have multiple keys that can be used for delegation.
[03:46:15] <pigdog> sender signing policy is in a separate policy.
[03:46:18] <hartmans> Although of course you might get information like whether verification is successful if you do upgrades
[03:46:23] <pigdog> one case we do define a binding to a header.
[03:46:48] <pigdog> for unsigned improperly or third party signed mail
[03:46:50] <pigdog> example
[03:46:56] <pigdog> please see the slides.
[03:47:04] <hallam> Ted - it is possible to use per-user keys with DNS keying, but there is not a lot of point going to that level if the signature can only be guaranteed to be checked for 1 day or so
[03:47:19] <pigdog> stuff in green are examples of places where these only have one value defined but there for future extension
[03:47:22] <pigdog> d=example.com
[03:47:34] <pigdog> this is the domain that actually signed it and who you consul.t
[03:47:41] <pigdog> i= who is authenticated.
[03:47:44] <hardie@jabber.psg.com> hallam: I was thinking that would be why you'd move to re-injection for per-user forwarding.
[03:47:49] <pigdog> s is the selector
[03:47:54] <pigdog> c= canonicalization algorithm.
[03:48:03] <arvel> there are actually two methods defined for c= - simple and nowsp
[03:48:13] <fanf> the selector allows you to implement practically any keying policy
[03:48:15] <pigdog> t= time stamp
[03:48:22] <pigdog> x= expiration
[03:48:29] <hallam> Ted, not following what you mean, I think end to end signature would probably require two sigs.
[03:48:42] <pigdog> time in seconds since 1970.
[03:48:53] <pigdog> h= what headers are signed.
[03:49:02] <pigdog> b=based 64 sig itself
[03:49:17] <pigdog> controversial points
[03:49:22] <pigdog> not using s/mime, pgp, pem...
[03:49:31] <pigdog> some of these we have answers to. some are more controversial.
[03:49:41] <pigdog> as to s/mime/pgp/pem.
[03:49:54] <pigdog> we had different goals. this is not intended to be strong enough to sign contracts.
[03:50:06] <pigdog> we still think s/mime PGP etc have a very important place in the world.
[03:50:33] <pigdog> i= & g= needed because of wildcard.
[03:50:46] <pigdog> body length counts (l=)
[03:51:03] <pigdog> there are potential security problems with this..
[03:51:10] <hartmans> I don't understand why per-user keying is not appropriate for roaming users if you can manage to solve the management issues.
[03:51:25] <pigdog> it seems to be pretty common to put innocuous cruft at the end of the message.
[03:51:47] <pigdog> concern per user keys in DNS may hurt DNS because of high load.
[03:51:50] <hardie@jabber.psg.com> When we're done with the preso, maybe Eric has an example we can work through (e.g. A5)
[03:51:51] <pigdog> eric agrees
[03:52:04] <pigdog> bad idea. don't do it.
[03:52:12] <pigdog> we need extensions to do this.
[03:52:18] <pigdog> real concern about replay attacks.
[03:52:22] <hallam> Sam, the only real challenge for per-user keying is to get key registration done. We don't want to re-invent PKIX CMP or XKRSS
[03:52:23] <pigdog> not a bug any more than in s/mime
[03:52:52] <pigdog> the entity that signed the message original is still responsible if the message gets resent. it's not a bug but a feature.
[03:53:03] <hartmans> So, um, it's an attack if it can be used for bad things even if you decide to keep it as a feature.
[03:53:16] <pigdog> canonicalization algorithms. we do have two in there. one simple. one called nowsp.
[03:53:43] <anewton> If per-user keying is a concern for DNS, why leave the g= value in the spec and why not take on other q= values for handling this problem now? In other words, don't leave the situation problematic, either take out the g= or look into new q= values now.
[03:53:48] <pigdog> i have personally (speaking only as me) been convinced that nowsp is too much. it hides line breaks, and may introduce security issues.
[03:53:48] <leifj> sam: scalability could be an issue for per-user keys too - compare with enum
[03:53:56] <pigdog> please god let's not have seven.
[03:54:39] <pigdog> keith moore: the thing about replay attacks depends on whether you're trying to build a a solution to spam or phishing.
[03:54:49] <pigdog> eric continues...
[03:55:25] <pigdog> we are not here to get a rubber stamp from the IETF. we have a lot of issues here. we put some stuff down as a compromise and welcome greater input.
[03:55:38] <pigdog> we still haven't even begun to define the RRs. need help from the DNS community
[03:56:04] <hallam> We have just deployed the RRs based on TXT, thats all
[03:56:05] <pigdog> the sender signing doc policy doc - i'm going to go back to the purported signer- needs a lot of work.
[03:56:41] <pigdog> the threats document that we discussed already. we did a security considerations that [turned into the threats document].
[03:56:49] <pigdog> it clearly needs some more work, however.
[03:56:54] <pigdog> end of eric's presentation.
[03:57:09] <pigdog> Dave: ONLY clarifying questions for now. any?
[03:57:10] <pigdog> ?
[03:57:42] <pigdog> pete resnick: you said that you didn't use S/MIME PGP, etc. it sounds like you gave reasons why it wasn't necessary. why wasn't it sufficient?
[03:57:53] <pigdog> eric: it violates the principle that naive users shouldn'
[03:57:58] <pigdog> shouldn't see changes.
[03:58:10] <pigdog> we wanted to avoid [certificate issues]
[03:58:10] <hartmans> Phil, I agree that we do not want to reinvent registration. I considered that the major management issue. Others seem to be saying that per-user keys is wrong for reasons besides that and DNS keys.
[03:58:23] <pigdog> if you have a mail reader that doesn't support S/MIME it's VERY visible.
[03:58:55] <pigdog> Ted Hardy: sections on affinity groups and forwarding, and A5. didn't understand goals. [what were your goals]
[03:59:02] <pigdog> eric: not sure of your questions.
[03:59:16] <hallam> Sam, remember that if the key is stored in the DNS your repudiation guarantees are going to be problematice
[03:59:19] <pigdog> eric: two types of forwarding. one that modifies the message and the other that does not.
[03:59:43] <pigdog> username@alumni.somewhere.edu [acm]. those are transparent forwarders and they should continue to work.
[03:59:45] <hallam> Sam - some folk worry that DNS cannot handle a zone with 40 million end-user keys (e.g. yahoo)
[03:59:55] <pigdog> path-based approaches have limitations.
[04:00:23] <pigdog> mailing-list exploders are a different thing. in those cases, best case those agents will resign the message.
[04:00:32] <leifj> hallam: there are ways around that if you don't use TXT - compare with enum
[04:00:41] <pigdog> there will be a period when we expect a certain number of signatures to fail.
[04:01:10] <pigdog> ted: [restates eric's goal, and that's what he wanted]
[04:02:07] <pigdog> pete resnick: do i understand that if a mailing list exploder only adds but does not change the headers will survive, assuming the sender has not prohibited adding specific headers, then the message will survive.
[04:02:31] <pigdog> if l= is specified on the beginning of a message, then adding stuff at the end will allow stuff to survive.
[04:02:42] <pigdog> even without l= many mailers should survive.
[04:02:51] <pigdog> dave: thank you eric.
[04:03:01] <pigdog> dave now has the floor
[04:03:12] <pigdog> poll: how many people have read the spec?
[04:03:23] <hallam> leifj - actually you can solve the problem with two level selectors, the real issue is that end-user keys that only persist for 24 hours are not much better than domain keys
[04:03:26] <pigdog> [n= "a bunch"]
[04:04:01] <hallam> leifj - if you want end user keys you really need a persistent key location mechanism like XKMS
[04:04:11] <pigdog> at this point the only ipr we know of is held by yahoo. and there has been concern expressed about when the ipr statement would be filed. miles levy will now speak to that.
[04:04:13] <pigdog> miles levy:
[04:04:25] <eric> libbey
[04:05:03] <pigdog> there is a patent around domain key technology. we expect to be able to make the ipr statement by 9/9 of this year. it will be at least as lenient as DK and we have abandoned any trademark claims.
[04:05:21] <pigdog> PTO rejected trademark as too descriptive which is probably a good thing.
[04:05:36] <pigdog> for the DK statement, go to domainkeys.sf.net (sourceforge)
[04:05:46] <pigdog> and if you can't find that, see the domain keys draft.
[04:05:58] <pigdog> that would be a patent application and not a patent at this point.
[04:06:32] <pigdog> dave: Thank you Miles. No Q&A on this because there's no filing to discuss.
[04:06:33] <pigdog> yet
[04:06:39] <pigdog> Now Charter discussion
[04:07:05] <pigdog> Jim will make a short presentation.
[04:07:41] <pigdog> william ebson: clarification... can we form a working group prior to 9/9?
[04:07:53] <Barry Leiba> (William Leibzon)
[04:07:56] <pigdog> dave: i don't know that to be true, and we don't have to answer that question right now.
[04:08:17] <pigdog> russ housley. WG is impossible to be formed that fast anyhow.
[04:08:48] --- shima has left
[04:08:48] --- shima has become available
[04:09:19] --- admcd has left
[04:09:29] --- mass has left
[04:09:29] --- pguenther has left
[04:09:30] --- paulmdx has left
[04:09:30] --- cnewman has left: Disconnected
[04:09:30] --- james has left
[04:09:31] --- arvel has left
[04:09:32] <hardie@jabber.psg.com> Bye yall
[04:09:34] --- hardie@jabber.psg.com has left
[04:09:37] --- dblacka has left
[04:09:38] --- Hollenbeck has left
[04:09:41] --- rbless has left
[04:09:44] --- raeburn has left
[04:09:44] --- robertml has left
[04:09:46] --- Jeffrey Altman has become available
[04:09:51] <hartmans> Another thing that will work is that if someone has stpeter's jid writing him and asking for a reconfiguration would be good
[04:09:51] <pigdog> William: IPRneeds to be discussed as part of the discussion
[04:10:08] <pigdog> jabber room is full. people leaving are freeing up space for others. meeting continues.
[04:10:33] <pigdog> Charter now being displayed.
[04:10:36] <pigdog> paragraph 1.
[04:10:49] <leifj> well if everyone in the room leaves then the value of the jabber-conference drops sharply... hmm
[04:10:54] --- poggij has become available
[04:11:10] <Jeffrey Altman> st.peter is not online at the moment
[04:11:10] <pigdog> leifj: those who are not at IETF may find it valuable.
[04:11:20] <leifj> I am not at the ietf
[04:11:27] <pigdog> there are two drafts draft-allman-dkim-*.txt
[04:11:36] <pigdog> jim now reading charter aloud
[04:11:41] <leifj> jabber room is great as a link between those on-site and others
[04:12:03] <pigdog> the spec is not cast in stone but we don't want to make gratuitous changes.
[04:12:09] --- Jeffrey Altman has left
[04:12:20] <pigdog> we are asking that we start at this point.
[04:12:59] <pigdog> working group will also cover signing policy as to what mail within a domain is signed.
[04:13:12] <pigdog> next par
[04:13:17] <pigdog> what's out of scope
[04:13:53] <pigdog> FOR THE TIME BEING (we can change this in the future). please see the charter.
[04:14:43] --- shima has left
[04:14:48] <pigdog> since messages will be verified by MTAs and looked at by the users you would like MTAs to be able to mark up the messages in a meaningful way to the users as to results of message verification to the users.
[04:14:50] --- shima has become available
[04:15:04] <pigdog> there is a draft. probably needs work as well.
[04:15:06] <pigdog> goals and milestones.
[04:15:13] <pigdog> 10/05 threats and requirements
[04:15:21] <pigdog> 2/06 mass signature and RR specs.
[04:15:27] <pigdog> 5/06 policy spec in may
[04:15:50] <hallam> COMMENT the mechanism for communicating authentication results is a majorly complex work item
[04:16:25] <pigdog> hallam: message read
[04:16:35] <pigdog> open mike after open issues.
[04:16:42] <pigdog> open issues 1.
[04:16:58] <pigdog> is the intent to create standards track rfcs? yes.
[04:17:08] <pigdog> not trying to rubber stamp dkim drafts.
[04:17:42] --- arvel has become available
[04:17:45] <pigdog> allow extensions by building
[04:17:53] <pigdog> whether jim should be a co-chair.
[04:18:23] <pigdog> whether meta signatures should be in scope
[04:18:34] <pigdog> rendering to users sould be in scope?
[04:18:47] <pigdog> wording excludes checking of message content to address header replay
[04:18:57] <pigdog> "useful, to improve" should read "useful to improve"
[04:19:05] <pigdog> "minimal changes" shoul reads "necessary changes"
[04:19:24] <pigdog> add other i-ds (Murray's, Phil's, William's) as input docs.
[04:19:35] <pigdog> add "most likely" to "keys will be stored..."
[04:19:58] <pigdog> permit key discovery as well as storage. ability to use DNS to find out where a key is as well as to store the key itself.
[04:20:10] <pigdog> a change to put reputation in scope
[04:20:23] <pigdog> support X.509 certs in key records
[04:20:50] <pigdog> include investiation of security issues described in draft-housley-mass-sec-review and draft-otis-reputation
[04:21:02] <pigdog> should we consider downstream communication of authentication results?
[04:21:20] <pigdog> alternmative key retrieval mechanisms in the future.
[04:21:52] --- arvel has left
[04:21:56] <pigdog> Dave: we now have 15 minutes of open mike. Please preface comments with COMMENT:
[04:23:06] <pigdog> Jim Sharp[???] we need to be clear about what we mean by MTA.
[04:23:15] <pigdog> Dave: good point.
[04:23:15] <warlord> Schaad
[04:23:35] <pigdog> Jim: we use terms "signer" and "verifier"
[04:23:58] <hallam> COMMENT The para 2 items should be NON-GOALS rather than Ou of scope. If this group cannot explain how it relates to existing work in the field there is something very wrong. Moreover the proposal is to LINK TO predefined key retrieval mechanisms such as XKMS (poss SCVP) not design new ones.
[04:24:23] <pigdog> Pete Resnick: the document i saw on the net as a threat analysis is not a threat analysis. a threat analysis. what security issue is this mechanism supposed to stop. iin terms of charter bashing,
[04:24:41] --- arvel has become available
[04:24:42] <pigdog> i would prefer the single item was a threat analysis and then a recharter so that we know what problem we're trying to solve.
[04:25:37] <pigdog> russ housley: pete no. first WG raises the bar. [can't just get a charter until we have the treat analysis.]
[04:26:08] --- Love has become available
[04:26:09] --- tlr has become available
[04:26:27] <pigdog> hallam: ack
[04:26:31] --- Love has left
[04:27:11] <pigdog> Ted Hardie: would like to gauge the sense of the room on how hard to get input specs into output specs.
[04:27:28] <pigdog> Dave: don't understand request
[04:27:43] <pigdog> Ted: there is almost no discussion of the protocol.
[04:27:53] <pigdog> Ted: [and that's necessary]
[04:28:21] <pigdog> Keith Moore: DKIM is a major improvement over DK and IIM. forward step. don't construe the following to malign the document. and yet...
[04:28:48] <pigdog> ... chartering a working group specifically devoted to DKIM absent other issues may be a disservice.
[04:29:22] <pigdog> ... right now we get a lot of spam that nobody wants to see. so, most significant bit is whether we should charter group.
[04:30:08] <pigdog> ... the charter presumes that tweaking existing DKIM within epsilon is appropriate as an isolated act. until we understand how to build an authentication system that is useful for more than just phishing might be premature.
[04:30:13] --- romiglups has become available
[04:30:46] <pigdog> ... the other concern is that work might be separable between apps and security.
[04:31:47] <pigdog> doug otis: i tend to think that you're right that replay is a feature. however, replay abuse is a problem. i don't think the spec as written is sufficient. exclusion of reputation from charter concerns me that it doesn't raise reputation to an appropriate level of visibility.
[04:32:13] <pigdog> ... when it comes to trying to protect reputation there are a lot of things that need to be done and not in current drafts.
[04:32:45] <pigdog> jim fenton: with respect to reputation and accreditation, people are working on it....
[04:33:06] <pigdog> ... i'm not saying how you hook in... but how you make it suitable for future use of reputation/accreditation...
[04:33:26] <hallam> Jim: People are working on it but your proposed charter explicitly rejects their work
[04:33:33] <pigdog> andy newton: two charter comments. i would like to see an explicit statement with backward compatability with domain keys.
[04:33:47] <pigdog> [i didn't capture jim's full statement]
[04:33:59] <pigdog> word core should not been in there.
[04:35:00] <pigdog> scott hollenback: we're not trying to rubber stamp a particular solution, but there is minimal or necessary changes. concerned about chairs squashing discussion based on what minimal or necessary means.
[04:35:15] --- romiglups has left
[04:35:17] --- rlbob has become available
[04:35:41] <pigdog> william ?: also have a problem with "minimal" changes. concerned output documet will be same on input document.
[04:36:32] <pigdog> also all work will be done based on public keys in DNS. more than 1/2 of a size of a UDP packets.
[04:36:51] <marcos> William Leibzon
[04:37:07] <pigdog> ... in previous bof IIM used finger prints, which are [considerably smaller] than public keys.
[04:37:08] --- tlr has left: Disconnected
[04:37:32] <pigdog> not allowing comparing something else.
[04:37:58] <pigdog> jim: storing the key in dns instead of sending key in message is just a trade-off.
[04:38:25] <pigdog> William Leibzon: problem when you try to get a public key through DNS.
[04:39:06] <pigdog> EKR: might be more useful to talk technical issues since charter can't be finished until threat analysis. so...
[04:39:22] --- shima has left
[04:39:49] <pigdog> ... reasoning seems to be that i get a lot of spam and phishing and it's almost always forged. if i have a scheme that prevents this, I can prevent spam/phishing. Eric doesn't believe that.
[04:40:15] <pigdog> Jim: we think we've dealt with this issue. forgery protection and spam and phishing are examples....
[04:40:30] <pigdog> EKR: forgery protection is not important.
[04:40:37] <pigdog> [not sure i got that right]
[04:41:02] <pigdog> chris newman; good enough charter. doesn't have to be perfect. don't expand work beyond what's feasible.
[04:41:42] <pigdog> ... i feel strongly that the biggest risk to this effort is overpromising. this is an important tool that can help. [necessary but not sufficient argument]
[04:42:05] <hartmans> Jim, are you monitoring this room?
[04:42:22] <pigdog> chris: quality of document is above average for working groups that are successful.
[04:43:35] <pigdog> keith moore: if you believe that auth will solve spam problem then you're wrong. if you believe auth with reputation will solve spam, then you're wrong. not valid inferences [auth+reputation -> no spam]
[04:43:43] <pigdog> and this is alluded to in the spec.
[04:44:42] <pigdog> ... it's really important that we understand which problems we're solving.... danger is that we'll go off and create this work and it doesn't solve a problem. [examples]
[04:44:57] <wrs1864> COMMENT: It appears that there is space available in the jabber room
[04:44:59] <pigdog> second, doing this amount of work and fly us into a blind canyon...
[04:45:36] --- mass has become available
[04:45:37] <fanf> wrs1864 = wayne schlitt?
[04:45:40] <wrs1864> (wrs1864 == wayne schlit)
[04:45:47] <wrs1864> tony: yes
[04:46:11] <wrs1864> Erh, but I didn't spell my last name correctly. s/schlit/schlitt/
[04:46:18] <pigdog> pekka nikander: speaking for myself. observation: even if we don't understand the relationship between small and large problem, it's still useful to try to solve one or the other.
[04:46:46] <pigdog> ...while we may need to better specify what the small problem is, it's still a valid problem to solve.
[04:46:56] <pigdog> ... we may be able to use this tool to solve the bigger problem.
[04:48:17] <pigdog> nathaniel borenstein: i agree with what was just said. and to eric, we're going down a dead end road. time will tell, but ability to prevent or make much harder forgery is still useful. the meta problem is that there is no solution to the spam problem. it's relatively easy to shoot down a tool for spam, but it's still useful for forgery and that's good.
[04:49:14] <pigdog> dave: point of procedure. we've done 20/15 minutes. we have just less than 45 minutes. perhaps we have too much background as opposed to too little, the norm. we have some preconditions to get a WG going. not sure what to suggest.
[04:49:19] <hallam> COMMENT: Excluding the relationship of DKIM to existing work is a big mistake. It is one thing to say that DKIM will not re-invent PKIX quite another to demand that DKIM MUST NOT allow discussion of how to use PKIX certs with DKIM.
[04:50:22] <hallam> COMMENT the charter para 2 should state NON GOALS rather than OUT OF SCOPE
[04:50:43] <tonyhansen> Elliot: we should get a hum on Russ's original comment. Is DKIM itself the right solution to raise the bar? Should we charter DKIM to do so?
[04:50:54] --- arvel has left
[04:50:55] <pigdog> [thanks, tony]
[04:51:19] --- tlr has become available
[04:51:44] <pigdog> dave: we have both strong and concerns about charter text and dkim that need to get resolved. figuring out what the utility of dkim is is not a small point. that said...
[04:52:03] <pigdog> ... the "faith" might be strong enough that we know we want to proceed ahead.
[04:52:30] <pigdog> dave: I'm inclined to ask for a sense of the room.
[04:52:41] --- dblacka has become available
[04:52:43] <wrs1864> do we get to hum?
[04:52:57] <pigdog> question: is the sense of the room that dkim is the vehicle to raise the bar? - DON'T ANSWER YET
[04:53:03] <pigdog> Pete Resnick:
[04:54:01] <pigdog> there are clearly a set of folks in here who say you don't get to the charter until we answer the "why are we doing this" question. those people will answer no if we don't have a clear answer that question.
[04:54:29] <pigdog> dave: even though we're having a hard time stating utility, there are [still people who think] there's utility...
[04:54:38] <pigdog> ... and that's still useful info to know.
[04:54:52] <pigdog> Dave: with that in mind... [here comes the question]
[04:55:16] <pigdog> there are substantial number of preconditions, assuming those get done...
[04:56:12] <hallam> Why on earth is Dave persisting trying to ask a loaded question when Pete has already warned him it will backfire?
[04:56:25] --- danwing has become available
[04:56:32] <pigdog> question to the room: is DKIM appropriate for pursuing to create a working group and raise the bar? [not humming yet]
[04:56:35] <pigdog> ted hardie:
[04:56:46] --- ogud has become available
[04:57:00] --- KMK has become available
[04:57:15] <pigdog> how do we figure out, other than by faith, whether there's consensus in this room, if we don't discuss how we're going to get to the question, once those conditions have been met
[04:57:38] <pigdog> before you ask the question... say something like the following.
[04:57:56] <pigdog> there are clearly preconditions that need to be met. the judgement will be made on the dkim mailing list.
[04:58:23] <pigdog> ekr: is one of the conditions that this stuff be useful?
[04:58:24] --- HSchauer has become available
[04:58:35] <pigdog> keith moore: premature for charter discussion.
[04:58:37] <pigdog> ...
[04:59:09] <pigdog> ... how many people think that dkim is sufficiently useful for the IETF to charter a working group to work on it?
[04:59:23] --- sommerfeld has become available
[04:59:33] <pigdog> [debate between dave and keith]
[04:59:49] <pigdog> keith: not about charter.
[05:00:01] <pigdog> [and this isn't binding]
[05:00:12] --- stefans has become available
[05:00:28] --- ekr has become available
[05:00:34] <pigdog> please hum as follows:
[05:00:42] <hallam> COMMENT: I think DKIM can be made useful if we change your rubber stamp charter
[05:00:43] <pigdog> "i think it is useful"
[05:00:48] <pigdog> "i think it is not useful"
[05:00:53] <wrs1864> Hummm
[05:00:53] <pigdog> "i don't"
[05:00:56] <pigdog> "i don't know"
[05:01:02] <pigdog> please indicate in jabber your choice
[05:01:32] <wrs1864> I meant I think it is useful
[05:01:34] <hallam> useful
[05:01:38] <leifj> useful
[05:01:54] <fanf> o
[05:02:03] --- cnewman has become available
[05:03:02] <pigdog> randy: agree with ekr, others, chris comments about overpromising. suggestion: reduce goal to bounces to forged mail. that is a small enough goal that dkim can solve to be useful.
[05:03:10] <wrs1864> Hmmmm...... "Ses" "BATV" "ABBS"
[05:03:15] <pigdog> randy gallens:
[05:03:28] <pigdog> [that was randy gallens]
[05:03:39] <pigdog> dave: would those who don't know please ask short form questions.
[05:03:43] <eric> well, "gellens"
[05:04:07] --- anabolism@jabber.org has become available
[05:04:22] <pigdog> jim fenton: do people need more detail on dkim or do people need more detail on application of dkim and its effectiveness
[05:04:39] <wrs1864> I don't need more details...
[05:04:54] <pigdog> sam hartman: is it going to break stuff?
[05:05:40] --- tonyhansen has left: Disconnected
[05:05:45] <pigdog> jim ??: can we come close the fixing the problem without breaking stuff.
[05:05:54] <pigdog> ... why should i think my isp will adopt this stuff?
[05:06:16] <warlord> jim schaad
[05:06:41] <pigdog> [warlord/jim: i apologize for not getting his last name]
[05:06:59] <pigdog> ???: can we get a threat analysis?
[05:07:02] <warlord> (I just happen to know his name)
[05:07:07] <warlord> That was Kathleen Moriarty
[05:07:47] <pigdog> dave: most who don't have enough info want threat analysis.
[05:07:59] --- dotis has become available
[05:08:08] <hallam> What people want here is a problem statement, the 'threat analysis' provided is really an issues list
[05:08:17] <pigdog> dave: i'm not surprised doc didn't quite hit the target.
[05:08:48] <pigdog> keith moore: [space shuttle analogy]
[05:08:49] <anewton> hallam: that is my sense of the room
[05:09:04] <pigdog> [hallam/anewton: i may have misunderstood dave]
[05:09:07] <anewton> sorry, that was a message directed toward Phil.
[05:10:13] <pigdog> nathaniel borenstein: eric asked if it's demonstrably useful and sam asked if it would hurt anything. those are two different standards.
[05:10:46] <dotis> DKIM provides a good solution, provided it solves the DoS and replay problem. This is lacking from the well written draft and not addressed well in the charter
[05:10:46] <pigdog> ... and he prefers the standard of whether this will do any harm
[05:10:50] <anewton> [pigdog: you are doing a good job.]
[05:11:52] <pigdog> jeff mulligan: we decided to go to the moon and we got a lot of technology that we didn't presuppose we would get. and i agree with nathaniel. if it helps in SOME way in phishing and spam by authentication and reducing forgeries, it's still a good thing to do.
[05:12:18] <hallam> COMMENT It could help a lot more with phishing if the charter was changed
[05:12:29] <pigdog> dave: here's a question to think about. one possibility that the thing being called a threat analysis is really a simple couple of statements....[??]
[05:12:38] <pigdog> hallam: will get to you momentarily
[05:13:27] <hallam> COMMENT Unless you have a link to the PKIX work this is not going to be a very useful solution for the banks. The cousin domains problem makes authentication alone not a solution
[05:13:38] <pigdog> pete resnick: interesting use case to describe is way to sign mail without disrupting user. try to figure out what sets of things you're trying to solve that AREN'T already solved.
[05:16:03] <pigdog> Lixia Zhang: i see the problem slightly differently. we built an internet and applications with it. and people were nice and did nice things. there was no defensiveness. now the world has changed and there are lots of bad guys and we're still using tools for nice guys. dkim adds defensiveness and so we should encourage it. i agree with the statement about not overpromising, but it's going in the right direction.
[05:16:26] --- KMK has left: Disconnected
[05:16:52] --- fluffy has become available
[05:17:07] <pigdog> dave: 15 minutes to go. homework assignment.... utility statement/threat analysis not the same but close. need a compelling statement to sell utility. please post suggested language. ietf-mailsig@imc.org
[05:17:41] <pigdog> [warlord says] my name is EKR. if you don't like what i'm saying bounce to my address...
[05:17:47] <pigdog> ;-)
[05:18:14] <pigdog> Warlord: just because people don't see the use doesn't mean there isn't one. I'm EKR and you can bounce that back.
[05:18:56] <hallam> The point here is that we might stand a better chance of hitting the target if we bother to look at it
[05:19:35] <pigdog> Mike Thomas: If RFC 822 were before a WG today it allows wholesale forgery, it wouldn't pass muster. the question of utility [should be viewed as this being added to what RFC 822 might have included back then]
[05:20:27] <pigdog> Keith Moore: temptation to downgrade stated goals. that's not a service to us or anyone else. i suggest that we answer these questions:
[05:20:38] <pigdog> - do we believe this will help for spam, phishing, virii
[05:21:00] <pigdog> - for the sake of email authentication, do you believe this is a significant improvement over S/MIME, pgp, etc. and why?
[05:21:25] <pigdog> the claim is that [not annoying the user] is a good thing. that claim has not been examined.
[05:21:56] <pigdog> dave: Q to Russ: should we revector to dkim list sooner rather than later?
[05:22:40] <pigdog> the question is should we use mass mailing list or revector to dkim specific mailing list so that there is no history and baggage with mass. not that other work couldn't go on, but this work would go on with dkim
[05:22:47] <wrs1864> I say "no"
[05:23:10] <pigdog> [not much response yet]
[05:23:12] <hallam> Actually we should roll the list so the IPR notice can be embedded in the enrollement
[05:24:17] <pigdog> Scott Rosco: is this going to break anything? is there a reasonable probabilty it will reduce spam, please go ahead.
[05:24:40] <pigdog> arvel ?: it seems on its face to be useful.
[05:24:45] <pigdog> ... today we know nothing.
[05:25:08] <pigdog> ... otherwise we could tape over the peep holes ...
[05:26:01] <pigdog> Chris Newman: email system meant to be reliable. there are so many bounces right now that people can't tell what's getting through.
[05:26:14] <hallam> Perhaps we could ask people in the anti-phishing working group if the spec is likely to be of use
[05:26:16] <pigdog> comment lines are closed.
[05:26:22] <tlr> since when have headers anything to do with bounces?
[05:26:34] <hallam> Did any of mine ever make it ?
[05:26:41] <pigdog> doug otis: dkims' goals should be establishing accountable domains.
[05:26:43] <pigdog> hallam: yes
[05:26:48] <tlr> a bunch, yes
[05:27:05] <hallam> Didn't see any response from Dave or Jim
[05:27:16] <wrs1864> there wasn't any real response
[05:27:49] <pigdog> doug otis: doesn't think there's enough there yet to cover attack vectors to reduce spam.
[05:27:58] <anewton> hallam, they are not responding to everything being said.
[05:28:12] <wrs1864> s/everything/most things/
[05:28:51] <pigdog> ekr: i've just heard a bunch of justifications. sometimes it means it's generally applicable, sometimes people are justifying what they are trying to do. agrees with keith moore earlier comment
[05:29:35] <pigdog> barry libo: if we take the simplistic view that this can stop spoofing the question comes up why that is useful. [ekr concurs]
[05:30:05] <pigdog> next steps'
[05:30:17] --- dblacka has left: Disconnected
[05:30:18] --- arvel has become available
[05:30:29] --- Barry Leiba has left
[05:30:34] --- anewton has left
[05:30:40] <pigdog> there are people with really focused questions and really focused answers. please hold for 24 hours while we set up a new mailing list.
[05:30:48] --- tonyhansen has become available
[05:31:04] <pigdog> ekr: will people be "MASS" subscribed.
[05:31:06] <pigdog> dave: no
[05:31:31] <pigdog> chris newman: different work items.
[05:31:37] --- hartmans has left
[05:31:44] --- anabolism@jabber.org has left: Logged out
[05:31:48] --- warlord has left
[05:31:51] <pigdog> meeting is concluded
[05:32:01] --- arvel has left
[05:32:03] <wrs1864> thanks for scribing!
[05:32:03] --- pigdog has left
[05:32:06] --- fanf has left
[05:32:11] --- ogud has left
[05:32:13] --- stefans has left
[05:32:18] --- fenton has left
[05:32:23] --- HSchauer has left
[05:32:26] <hallam> thanks for scribing
[05:32:34] --- mass has left
[05:32:38] --- leifj has left
[05:32:48] --- hallam has left
[05:33:53] --- end has become available
[05:34:23] --- end has left
[05:35:50] --- tlr has left
[05:36:10] --- rlbob has left
[05:36:45] --- danwing has left
[05:36:56] --- eric has left: Logged out
[05:37:30] --- fluffy has left
[05:48:33] --- rbless has become available
[05:50:20] --- milele has left
[05:50:45] --- cnewman has left: Disconnected
[05:51:48] --- dotis has left: Disconnected
[05:52:31] --- marcos has left: Disconnected
[05:54:08] --- tonyhansen has left: Disconnected
[05:58:55] --- poggij has left
[06:06:38] --- ekr has left: Disconnected
[06:14:47] --- jlcjohn has left
[06:26:53] --- zerosixty has become available
[06:27:23] --- rbless has left: Lost connection
[06:47:12] --- zerosixty has left
[07:00:30] --- dcrocker has become available
[07:08:56] --- sommerfeld has left
[07:25:58] --- danwing has become available
[07:27:10] --- danwing has left: Replaced by new connection
[07:55:27] --- eric has become available
[08:01:16] --- eric has left
[08:21:23] --- dcrocker has left: Disconnected
[08:23:20] --- fluffy has become available
[08:35:20] --- fluffy has left
[08:36:25] --- jrlevine has become available
[08:39:01] --- dcrocker has become available
[09:37:40] --- dcrocker has left: Replaced by new connection
[09:37:41] --- dcrocker has become available
[09:44:29] --- jrlevine has left
[09:46:35] --- kmkaplan has become available
[09:47:01] --- kmkaplan has left
[09:59:00] --- dcrocker has left: Replaced by new connection
[09:59:03] --- dcrocker has become available
[10:34:34] --- dcrocker has left: Replaced by new connection
[10:34:36] --- dcrocker has become available
[10:53:08] --- dcrocker has left: Replaced by new connection
[11:12:09] --- NFreed has become available
[11:16:34] --- jrlevine has become available
[11:16:53] --- jrlevine has left
[11:34:04] --- wrs1864 has left
[11:51:55] --- earl has become available
[12:17:01] --- ddayman has left: Lost connection
[12:56:33] --- jrlevine has become available
[12:56:42] --- jrlevine has left
[13:27:43] --- earl has left: Disconnected
[14:30:09] --- NFreed has left: Disconnected
[15:27:55] --- jrlevine has become available
[15:28:06] --- jrlevine has left
[16:01:55] --- ogud has become available
[16:05:15] --- ogud has left