[08:59:38] --- dcrocker has joined
[09:03:00] --- dcrocker has left
[11:19:09] --- wrs1864 has joined
[11:28:33] --- wrs1864 has left: Disconnected
[11:38:20] --- wrs1864 has joined
[11:44:40] --- PaulMdx has joined
[11:45:08] --- PaulMdx has left
[11:46:03] --- PaulMdx has joined
[11:46:42] --- PaulMdx has left
[14:14:17] --- Dave Cridland has joined
[14:45:23] --- PaulMdx has joined
[14:47:26] --- kmurchison has joined
[14:51:16] <Dave Cridland> Just to double-check, it is 12:50 in Vancouver now, right?
[14:51:28] <kmurchison> yes
[14:51:39] <Dave Cridland> Lovely, thanks Ken.
[14:53:18] --- tonyhansen has joined
[14:54:50] --- NFreed has joined
[14:55:03] --- arvel has joined
[14:57:27] --- hartmans has joined
[14:57:37] --- fenton has joined
[14:57:50] --- anewton has joined
[14:58:13] --- stephenfarr has joined
[15:00:29] --- EliotLear has joined
[15:01:12] <EliotLear> good afternoon
[15:01:22] <Dave Cridland> Evening. :-)
[15:01:29] <PaulMdx> Evening for me too. :)
[15:01:43] <PaulMdx> How's Vancouver?
[15:02:22] <EliotLear> vancouver is cool but pleasant. we are ready to start. this is eliot lear. i will be jabbering. if you have a question and would like it asked, please preface with ASK:
[15:02:36] <tonyhansen> vc's a nice city
[15:02:38] --- hta has joined
[15:03:12] <wrs1864> what URL?
[15:03:17] <EliotLear> administrivia, agenda
[15:03:20] <anewton> eliot, thanks.
[15:03:37] <EliotLear> http://www3.ietf.org/proceedings/05nov/agenda/dkim.txt
[15:03:39] <wrs1864> (thanks also, Eliot)
[15:03:51] <EliotLear> scribes (there may be another)
[15:03:57] <EliotLear> blue sheets going around
[15:04:10] --- mstjohns has joined
[15:04:18] --- patrik has joined
[15:04:29] --- joshlitt has joined
[15:04:49] <EliotLear> jim schaad will be calling out questions if he can get in. otherwise i will
[15:04:55] <EliotLear> Agenda:
[15:05:03] <EliotLear> Agenda ( Farrell)
[15:05:17] <EliotLear> charter walkthrough (leiba)
[15:05:21] <EliotLear> Charter Discussion
[15:05:29] <EliotLear> Threat Analysis (Fenton)
[15:05:37] <EliotLear> Base/Policy Spec (Allman)
[15:05:48] <EliotLear> Stephen: please hold technical questions toward the end.
[15:05:54] <EliotLear> level setting
[15:06:20] <EliotLear> Question: how many people read the draft charter: 50%
[15:06:40] <EliotLear> another 20% have read a draft but not the latest
[15:06:48] <EliotLear> What's DKIM's goal:
[15:07:09] <EliotLear> create a standard for primarily MTA-MTA accountability
[15:07:21] <EliotLear> next level down:
[15:07:35] <EliotLear> allow sending domains to accept responsibility, to take accountability for messages they are sending out
[15:07:40] --- hardie@qualcomm.com has joined
[15:07:55] --- lha has joined
[15:08:10] <EliotLear> additionally, receiving domains can do something with this, by treating messages that don't have sigs for more suspicious (for example)
[15:08:27] <EliotLear> make whatever we do resistant to "workarounds"
[15:08:32] <EliotLear> try to avoid signature failures
[15:08:34] <EliotLear> don't do harm
[15:08:40] --- doug_trendmicro@jabber.org has joined
[15:08:48] <EliotLear> if people are not using dkim we shouldn't be causing them difficulty
[15:09:05] --- mrichardson has joined
[15:09:12] --- mrichardson has left: Logged out
[15:09:19] <EliotLear> enable other anti-spam services by increasing confidence mail handling tools can have in their inputs
[15:09:26] --- rvdp has joined
[15:09:34] <EliotLear> <Analogy between domain name and IP address as filter>
[15:10:07] --- eric has joined
[15:10:12] <EliotLear> what does dkim do?
[15:10:14] --- mrichardson has joined
[15:10:29] <EliotLear> allows domain to assert that it is accountable for a message, by doing this in the headers
[15:10:50] <EliotLear> from the receiving side this is just another input in anti-spam analysis
[15:11:22] <EliotLear> standardizing what happens next with regard to anti-spam activities is NOT a part of DKIM
[15:11:29] <NFreed> Is anyone online actually in the room in Vancouver?
[15:11:38] --- NFreed has left
[15:11:40] <EliotLear> <yes>
[15:11:50] --- NFreed has joined
[15:11:55] <hta> yes
[15:11:56] --- stephenfarr has left: Disconnected
[15:11:58] <EliotLear> we may be able to get message body integrity checks
[15:12:03] <EliotLear> how does it work?
[15:12:06] --- doug_trendmicro@jabber.org has left: Replaced by new connection
[15:12:11] <EliotLear> intended primarily for MTA to MTA, hence domain
[15:12:20] <EliotLear> outbound MTA signs and adds new headers
[15:12:29] <EliotLear> public keys and other data in originating domain's DNS
[15:12:36] --- NFreed has left
[15:12:58] <EliotLear> there is room for debate as to why that's the case, but there is some level of "out of bandness" being provided this way
[15:13:05] --- NFreed has joined
[15:13:38] <EliotLear> on the verifier side, if the signature is present the verifier can then look up the public key, validate and then react in some way.
[15:13:50] <EliotLear> again, what that reaction is is beyond scope today
[15:13:52] --- dcrocker has joined
[15:14:29] <EliotLear> if you want to handle things a bit more subtlely, there is sender signing policy, where you can look it up and determine what happens when the signature is missing.
[15:14:38] <EliotLear> this is less mature than the base spec, work to be done
[15:14:50] <EliotLear> omitted details, but there's the intro
[15:14:55] <EliotLear> what's it not for?
[15:15:19] <EliotLear> - deleting mail messages, actions subsequent to verifier signature processing are out of scope. no MUSTs there at all
[15:15:25] <EliotLear> reputation service- out of scope
[15:15:33] --- Melinda has joined
[15:15:39] <EliotLear> confidentiality. S/MIME or PGPG for that
[15:16:08] <EliotLear> (that's the last slide)
[15:16:19] <EliotLear> there is running code, in experimental state. proposal is not out of nowhere.
[15:16:31] <EliotLear> IPR is "in hand". Yahoo has provided a statement...
[15:17:00] <EliotLear> there is a community who recognize the utlity of DKIM and who have (IMO anyway) reached some rough consensus
[15:17:11] <EliotLear> there is also a well worked draft charter
[15:17:23] <EliotLear> and a group who have reacted well to the Paris BoF
[15:17:31] <EliotLear> Hopefully we'll have a working group next time.
[15:17:47] <EliotLear> thinks the group has reacted well to comments made in Paris
[15:18:09] <NFreed> is this working?
[15:18:18] --- NFreed has left
[15:18:37] <EliotLear> hold comments for now...
[15:18:37] <EliotLear> <Barry Leiba on revised charter>
[15:18:37] <EliotLear> <yes, ned i see you>
[15:18:44] <EliotLear> proposed charter
[15:18:49] --- resnick has joined
[15:19:06] <EliotLear> first paragraph: motivation.
[15:19:19] <wrs1864> is there a URL for the slides/presentations?
[15:19:28] <wrs1864> (I saw the URL to the agenda earlier...)
[15:19:38] <EliotLear> this next paragraph talks about publishing the threats document that discusses what threats to address
[15:20:12] <EliotLear> the presentation is in the "meeting materials" web site. patrik will point it out in a moment
[15:20:23] <wrs1864> (thanks)
[15:20:25] <patrik> <slow network here...>
[15:20:25] <EliotLear> we don't claim that this will stop phishing, spoofing, or spam.
[15:21:10] <EliotLear> we hope to have a way to sort through different levels of confidence , and a notion of some of the things we might do
[15:21:13] <joshlitt> http://onsite.ietf.org/proceedings/05nov/slides/dkim-0.ppt
[15:21:24] <PaulMdx> Thanks Josh.
[15:21:37] <wrs1864> thanks
[15:21:38] <patrik> http://www3.ietf.org/proceedings/05nov/agenda/dkim.txt
[15:21:51] <EliotLear> next: where we are starting is draft-fenton-dkim-threats, draft-allman-dkim-base, draft-allman-dkim-ssp
[15:22:09] <EliotLear> these are preworking group drafts, but based on work done by industry consortia et al.
[15:22:17] <EliotLear> <Arvel Hancock>
[15:22:31] <wrs1864> https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64 contains links to other presentations.... (search for dkim)
[15:22:36] <EliotLear> 3 companies did some interoperability testing.
[15:22:37] <fenton> s/Hancock/Hathcock/
[15:23:16] <EliotLear> as it stands, all three implementations operate completely. there are two other implementations that are now also tested and interoperating just fine at the "signing and verifying" level. the two have not implemented SSP
[15:23:35] <patrik> (thanks wrs et.al. my network connection is soooooooo sloooooooowwwwwwww,,,,,,)
[15:23:54] <EliotLear> there have been 1000s of downloads of several different versions and many people are using it. we had an interop telephone conference in which several participants announced forthcoming implementations
[15:24:37] <EliotLear> one other point: the existing implementations are an implementation of -00 version of the spec. Mike Thomas has begun implementing -01.
[15:25:02] <EliotLear> Statement from Bank of America that he is authorized to read.
[15:25:26] <EliotLear> <Keith Moore> why is this relevant? i think we're wasting time with marketing.
[15:25:50] <wrs1864> (please talk into the mic!)
[15:25:53] <EliotLear> <Barry> fair point, i'm just trying to show that substantial work has been done in this space
[15:26:03] <resnick> Keith's mic was not working.
[15:26:10] <EliotLear> <Barry>
[15:26:51] <EliotLear> we understand that reputation and accreditation is important , but we are not going to develop taht work here.
[15:27:00] <EliotLear> deliverables
[15:27:09] <EliotLear> an informational rfc describing threats
[15:27:24] <EliotLear> an informational rfc describing an overview of the system.
[15:27:33] <EliotLear> decisions made both prior to the working group and in the working group can be documented
[15:27:55] --- jimsch has joined
[15:27:56] <EliotLear> specifications for how to do signing and verification, and for publishing policies, and a specification for a new DNS RR
[15:28:13] --- dkim has joined
[15:28:15] <EliotLear> milestones: 02/06 last call on thredats
[15:28:22] <EliotLear> 05/06 base specification last call
[15:28:27] <EliotLear> 09/06 last call on the rest of the work
[15:28:47] <EliotLear> one reason for the aggressive calendar is the existing work that is out there. we want to get this out there quickly.
[15:28:56] <EliotLear> going back to beginning.
[15:29:13] <EliotLear> <Doug Otis>
[15:29:20] <EliotLear> Mike not working (yet).
[15:29:29] <EliotLear> now it is
[15:30:33] <EliotLear> DKIM is a wonderful idea, deploy it quickly. my concern is more regarding SSP policy draft and how it is worded. in terms of the charter, you are making statements that there are legitimate reasons for From: and you're making statements about replicating efforts of the author.
[15:30:35] --- arvel has left: Replaced by new connection
[15:30:43] --- mstjohns has left
[15:30:54] --- arvel has joined
[15:31:28] <EliotLear> DKIM without policy records would be 1000x better than what we have today. but applying policy will be abused because you will shift the accountability of the signer onto the email domain owner and we don't want to see that happen. accountability has to remain with the administrator of the transport [agent].
[15:31:42] <dkim> What does any of this have to do with the charter?
[15:31:51] <EliotLear> the policy spec is way of shifting that responsibility and we don't want to see that happened. "I allow/don't allow third party signers".
[15:31:55] --- dkim has left
[15:32:10] --- NFreed has joined
[15:32:27] <EliotLear> <barry> we agree that the policy document is immature. if the group said that the signing policy is considered harmful, that would be a valid output of the group.
[15:32:53] <EliotLear> <Doug Otis> i apologize to jim or others for rewriting the draft but i was trying to illustrate this problem
[15:33:23] <EliotLear> <Keith Moore> the problem with the charter implies that it solves a problem we understand without us really examining the underlying problem.
[15:33:58] <NFreed> Has Keith read the threat analysis?
[15:34:28] <EliotLear> there are lots of people who use blacklists, etc. we could charter working group without being confident that we will solve a real problem. i think we will skip these very important discussions because people are afraid to have them.
[15:34:40] <wrs1864> I suspect he has, and I suspect he disagrees with many assumptions in it.
[15:35:13] <EliotLear> <barry> i think we have had a good bit of discussion.
[15:35:13] <EliotLear> <mike thomas> we've had discussion for 1.5 years
[15:35:32] <hartmans> In particular, I don't think considering dkim separate from reputation allows us to evaluate whether we have successfully solved any problem or whether we just broke the email architecture.
[15:36:15] <Dave Cridland> I'm wondering if anything else was ruled out of scope, would there be anything that DKIM actually did.
[15:36:23] <NFreed> Well, I personally offered to try help Keith articulate his concerns offline. He thought that was a great idea and then never
[15:36:26] <NFreed> sent another word to me.
[15:36:28] <EliotLear> <barry> one thing we think is useful is that suppose that bank of america sends out lots of mail to its customers. right now a lot of their mail gets deleted as phishing or suspected phishing or people can't turn their filters up for fear of deleting legitimate mail.
[15:36:28] <EliotLear> <doug otis> you don't need SSP to achieve that
[15:36:38] <hartmans> I don't think that people are considering the big picture. I think they are trying to limit the scope to what we can reasonably get consensus on.
[15:36:43] --- resnick has left: Disconnected
[15:36:57] <EliotLear> <keith> if you're trying to solve the phishing problem that is a great discussion to have. what i see now is what looks like handwaving. can we get to a level where we can discuss more details...
[15:37:01] <hartmans> And as a result I'm concerned that we are narrowing a scope to a point where we cannot guarantee reasonableness of solution.
[15:37:53] <EliotLear> <chris newman> i partially agree with keith, but i think it's SSP and not the base spec. to do research on reputation etc, you need a stable base to experiment. the base spec is that important stable base.
[15:38:04] --- dcrocker has left
[15:38:07] --- mstjohns has joined
[15:38:12] <Dave Cridland> If this is all about research, isn't this a job for the IRTF, or am I misunderstanding something?
[15:38:23] <EliotLear> <barry> keith, please propose some additional text to clarify the situation
[15:38:24] <NFreed> You're misunderstanding something.
[15:38:30] <EliotLear> <harald> conclusion of the discussion?
[15:38:47] <EliotLear> <barry> only substantive comment was keith's and he'll provide some additional wording
[15:38:47] <hartmans> No, you can have standards track protocols or experimental protocols to support research.
[15:38:55] <hartmans> Take a look at HIP as an example; both a wg and rg
[15:39:00] <mrichardson> ned? come again?
[15:39:21] <EliotLear> <jim fenton on the threats draft>
[15:39:30] <NFreed> The point Chris tried to make is that the research aspects of this cannot be explored until there is a platform to explore from.
[15:39:34] <Dave Cridland> Sam, yes, true. So do we need to be considering which parts of this are a WG, and which are an RG?
[15:39:45] <NFreed> The creation of that platform is in no way, shape, or form research.
[15:39:58] <EliotLear> i codified what people were thinking in the threat analysis document
[15:39:58] <EliotLear> draft-fenton-dkim-threats-01.txt
[15:40:00] <Dave Cridland> Ned, Chris wasn't the first to talk about researching things, though.
[15:40:01] <EliotLear> there is a lot of uncertainty about what constitutes a threat analysis. i tried not to focus on that...
[15:40:13] <mrichardson> research FOO requires deployed technology BAR.
[15:40:21] <EliotLear> i tried to focus on whether dkim does something useful and what threats dkim addresses.
[15:40:21] <NFreed> I think having an IRTG activity in the general area of reputation systems makes a lot of sense.
[15:40:26] <hartmans> Dave, no comment.
[15:40:37] <NFreed> The question is whether or not there would be anyone interested in actually working on the problem.
[15:40:40] <mrichardson> research FOO will not change technology BAR, but rather, build something new upon it.
[15:40:43] <EliotLear> four parts; who are the bad actors? what are they capable of? where do they exist in the message flow, and what are they trying to accomplsih
[15:40:48] <EliotLear> there are things that aren't there.
[15:40:55] <NFreed> Repeated attempts to generate such interest in, say, the ASRG forum have not been successful.
[15:41:00] <EliotLear> i didnt' characterise threat in terms of spam or phishing
[15:41:05] --- resnick has joined
[15:41:27] <EliotLear> there are bad acts that don't involve spam or phishing that we are trying to address
[15:41:44] <EliotLear> there is a benefit in some sort of signature representing someone taking responsibility for the message
[15:41:52] <EliotLear> there are different understandings of the term "forgery
[15:41:54] <EliotLear> "
[15:41:58] <NFreed> It isn't even necessary to assert that research FOO will not change technology BAR. Iteration is good.
[15:42:11] --- dcrocker has joined
[15:42:13] <EliotLear> we aren't making an assertion of authorship so "forgery" may not be the right word
[15:42:18] <mrichardson> BAR+FOO == BAR++.
[15:42:25] <NFreed> But iteration requires a starting point. (Unless you're talking about Conway's field ;-)
[15:42:34] <EliotLear> we're trying to provide some assurance of somebody is taking responsibility
[15:42:50] <EliotLear> i didn't use the term "repudiation" because there may be different meanings to this word
[15:42:55] <mrichardson> so, ned we're in agreement. I wasn't trying to disagree, just clarify.
[15:42:55] --- arvel has left: Disconnected
[15:43:02] <NFreed> Ack.
[15:43:12] <tonyhansen> <soapbox> there's been *so* much navel gazing over the past few years on "the big picture". I'm sorry, but I'm convinced that: 1) yes, there needs to be people looking at the big picture, but 2) a proposal to work on a small part of the big picture shouldn't be blocked while we continue looking at our navels. </soapbox>
[15:43:15] --- jeaton has joined
[15:43:15] <EliotLear> the analsyis is specific to DKIM because that is the working group we are considering
[15:43:24] <hta> Chris' comment (as I heard it) was that if you can't verify a sender, all reputation systems are open to a trivial attack. so if you want to have any kind of reputation system, you need a verifiable identity to assert the reputation of....
[15:43:39] <EliotLear> there are a number of threats we do not address, and this was designed for the chartering decisions, this is the work that was done up till now.
[15:43:39] <NFreed> Tony, you're absolutely right.
[15:43:58] --- resnick has left
[15:43:58] --- resnick has joined
[15:44:05] <EliotLear> if this becomes a working group, then the draft will become a WG draft, in which case the draft may well change rather dramatically
[15:44:18] <NFreed> Harald, careful. "Verify a sender" is loaded in various ways. What DKIM does is let you attach a responsible identity.
[15:44:23] <NFreed> That's enough.
[15:44:30] <hartmans> tonyhansen: I agree with you provided that you can convince me that you don't break things while working on the big picture.
[15:44:49] <EliotLear> also, russ stated at the beginning of the Paris BOF that there could be other WGs in this space that could get chartered. that's another reason for the analysis to be focused on dkim
[15:45:02] <hartmans> Basically, convince me that you aren't breaking mailing lists, mail forwarding, road wariers, etc too much and I'll agree working on dkim without the big picture is fine.
[15:45:02] <EliotLear> there are a few places that threats could be described.
[15:45:15] <EliotLear> this document talks about threats PRIOR to DKIM usage.
[15:45:16] <Dave Cridland> Tony, I'm not disagreeing with that standpoint, as a general rule. But a proposal to build a small part of a big picture implies that the small part of the big picture *is*, in fact, a small part of a big picture.
[15:45:37] <EliotLear> there are two places that threat analysis can go. i've chosen to talk about threat environment in the threats draft
[15:45:44] <hartmans> Or rather while working on the small part of the problem
[15:45:51] <EliotLear> eric and i put threats TO dkim in Security Considerations of the base and SSP drafts
[15:46:13] <EliotLear> it's difficult to do a complete job of threats TO dkim when the spec isn't finalized.
[15:46:42] <EliotLear> there are a few important attacks to DKIM that are there because they impact service generally
[15:46:50] <EliotLear> replay is one example
[15:46:54] <EliotLear> handling of unsigned message
[15:47:05] <EliotLear> lookalike and throw away domains
[15:47:15] <EliotLear> key management vulnerabilities
[15:47:37] <EliotLear> look for changes as the document matures
[15:47:47] <EliotLear> first deliverable in the draft charter
[15:48:03] --- rvdp has left
[15:48:06] <EliotLear> also because it is the first deliverable we can only so much about threats to the protocol
[15:48:20] <EliotLear> there needs to be a lot of specific thought to SSP
[15:48:55] <EliotLear> we want a complete threat analysis
[15:49:11] <EliotLear> do we consider the example of someone bribing the system administrator to get a domain key
[15:49:14] <EliotLear> (private key)
[15:49:17] <hartmans> I'm unsure that this part of the discussion matters for the bof
[15:49:18] <patrik> Sam, regarding road warier, I would like to know what you believe the normal road warier is doing when being on the road. I think they can: (1) use outgoing MTA on their laptop, (2) use local mta close according to network topology and (3) same outgoing mta as when being at home. As the three major cases.
[15:49:31] <NFreed> Well, we certainly inherit all the various attacks on the underlying crypto. But do we really want to cover all that
[15:49:36] <NFreed> in the threat analysis?
[15:50:01] <EliotLear> <Eric Allman now discusses other specifications>
[15:50:12] <EliotLear> Some of these slides are repeats from Paris.
[15:50:18] <NFreed> How about a pointer to an outside analysis?
[15:50:20] <EliotLear> <Barry> but we want to keep fond memories of Paris ;-)
[15:50:35] --- mstjohns has left
[15:50:38] <EliotLear> [Ned: outside analysis?]
[15:51:04] <Dave Cridland> Eliot: As in, of the crypto itself, rather than the specifics of DKIM.
[15:51:07] <hartmans> patrik: I think all of these are common
[15:51:13] * hartmans falls into case 1 currently.
[15:51:14] <EliotLear> goal: allow the good senders to provide evidence that they did send a particular message.
[15:51:16] <NFreed> There are entire books on attacks on crypto mechanisms. I have a shelf of them. I see no point in discussing
[15:51:35] <patrik> sam: what I thought :-)
[15:51:35] <EliotLear> dramatically increase the difficulty of forgers. this really does require something like SSM.
[15:51:36] <NFreed> things like timing attacks in the threat analysis unless those attacks are specific to DKIM and not inherent in
[15:51:42] <NFreed> the use of, say, RDSA.
[15:51:47] <NFreed> Sorry, RSA.
[15:51:48] <EliotLear> this is not an anti-spam tech by itself.
[15:51:55] <Dave Cridland> hartmans: Most people are in case 2, I think. And they're totally screwed by DKIM.
[15:52:00] <EliotLear> Model picture now on screen
[15:52:07] <hartmans> Ned, I tend to agree. Well, if there are any desgn flaws that make particular attacks more important for DKIM than usual that should be called out.
[15:52:21] <EliotLear> MUA->submit->MTA->Intermed MTA -> MTA/Verifyer -> MS -> MUA
[15:52:26] <hta> I think the timing stuff is a red herring. the threat model does not consider threats from an attacker with a presence on the originating MTA. (probably needs to say that)
[15:52:38] <EliotLear> there can be optional intermediate MTAs as long as they don't mangle the message
[15:52:52] <EliotLear> somewhere close to the MUA you verify the message.
[15:52:55] <hartmans> Case 2 can be supported by per-user keys and a MUA that does dkim signatures.
[15:52:57] <NFreed> Sam, the folks who use, or attempted to use, a local MTA, are scewed, period. DKIM has nothing to do with it.
[15:53:00] <patrik> sam: FYI (1) can be solved by also making sure you do secure dynamic update of dns, (2) is hard, require a user-based-key and (3) is of course easy.
[15:53:09] <EliotLear> DKIM runs between unrelated administrative domains
[15:53:27] <EliotLear> you don't have to sign at the edge as long as the edge doesn't mangle the message. so the MSA could do the job
[15:53:41] <EliotLear> you could push it back to the MUA but that's probably not a popular way of doing it
[15:53:55] <EliotLear> mailing list managers are probably the most problematic in terms of message mangling
[15:53:59] <EliotLear> design goals:
[15:54:00] <hartmans> Ned, sorry, but that's not how our email architecture works today. I don't mind you getting an ietf consensus to *change* that but until you do, you need to work with that.
[15:54:13] <EliotLear> 1. low cost (avoid large pki)
[15:54:29] --- dcrocker has left
[15:54:30] <EliotLear> - don't create new services
[15:54:33] <Dave Cridland> hartmans: He has a point - many MTAs reject mail outright from DSL and dialup IP ranges.
[15:54:35] <NFreed> Sam, I don't know what world you're operating in, but this is NOT the email architecture I see people deploying today.
[15:54:36] <EliotLear> 2. no trusted third parties
[15:54:50] --- dcrocker has joined
[15:54:53] <EliotLear> - different administrative entities such as CAs or key escrow
[15:54:54] <NFreed> And large scale email deployments are what I do.
[15:55:04] <EliotLear> 3. shouldn't require MUA upgrades
[15:55:04] <hartmans> (1) actually seems to require per-user keys more than dynamic dns update.
[15:55:12] <hartmans> I don't use my own domain but I do use my own mta
[15:55:18] --- arvel has joined
[15:55:38] <EliotLear> 4. naïve end users shouldn't see any significant changes. life should only get better. this is why S/MIME wasn't a good fit
[15:55:47] <EliotLear> - to the extent possible should be invisible
[15:55:55] <hartmans> Ned, I'm talking about the architecture supported by our specs.
[15:55:57] <arvel> Statement from Steven Jones of BoA: Bank of America is aggressively pursuing email authentication solutions to protect our customers and our business. Standardizing DKIM is very important to our strategy, and has a direct impact to our business and our customers' security. We need clear and authoritative standards for these technologies so that our deployed solutions will interoperate. We hope that our support for and involvement with DKIM standardization will speed that process.
[15:55:58] <EliotLear> 5. allow sender delegation for outsourcing
[15:56:09] <NFreed> Using your own MTA is case 1. We're talking about case 2, using a network-local MTA.
[15:56:15] <EliotLear> [thanks, arvel - glad i didn't have to type that]
[15:56:22] <EliotLear> 6 extensibility
[15:56:28] <resnick> David: Why do you think most people are (2) and not (3)? I would think that (3) would be much more common.
[15:56:29] <arvel> np :)
[15:56:30] <hartmans> I as an IESG member am very reluctant to charter work that breaks things without an ietf consensus to say that breaking those things is OK.
[15:56:31] <EliotLear> 7 wanted a structure usable for per-user signing
[15:56:32] <hta> sam, I think the people who Ned points out are screwed are the people who try to send mail in their own name by submitting to a random MTA that "happens to be close to them".
[15:56:44] <EliotLear> new key services would be a prereq for per user signing
[15:56:48] <Dave Cridland> hartmans: FWIW, I'd definitely agree that a specification outlining the email architecture would be very useful for many people.
[15:56:55] <EliotLear> Technology
[15:56:57] <hta> Ned, am I paraphrasing you correctly?
[15:57:02] <EliotLear> DKIM signature is self-signed
[15:57:05] <NFreed> And my point is that the things you claim DKIM will break are already broken. DKIM isn't going to break them any more.
[15:57:08] <EliotLear> signature includes signing identity
[15:57:20] <NFreed> In fact there in some cases, such as your case 1, DKIM may actually help.
[15:57:23] <EliotLear> we will explicitly list the identity in the signature header
[15:57:31] <EliotLear> the binding of what the user sees is a separate issue
[15:57:38] <EliotLear> we'll store the public key in DNS
[15:57:42] <Dave Cridland> Ned, no, that's not true. I'm pretty sure that case 2 is hurt by DKIM, although case 3 is cleaner, and we should be moving that way.
[15:57:46] <EliotLear> short run we'll use TXT, long run a new RR
[15:58:00] <EliotLear> 'use _domainkey subdomain
[15:58:23] <EliotLear> a domain can have a number of keys, perhaps a few, perhaps some for outsources, perhaps for aging out old keys
[15:58:32] <hartmans> And my point is that you're chartering work that depends on breaking them; that's different than having current operational practice break them.
[15:58:38] <EliotLear> DKIM example signature field
[15:58:40] --- kivinen has joined
[15:58:54] <NFreed> Please explain how deploying DKIM is going to change the behavior of local MSAs.
[15:58:59] <hartmans> I think cable companies etc routinely encourage people to use network local MTAs even if the mail-from identity is not network-local.
[15:59:21] <hartmans> So, I think we at least need to have a BCP saying not to do that if we're going to have spec that would break.
[15:59:29] <EliotLear> d=signing domain a=algorithm i=identity part on left side is not part of the authentication.
[15:59:39] <hta> sam: "encourage" = blocking outgoing port 25, yes?
[15:59:48] <EliotLear> s=selector, departments could have different keys
[15:59:51] <Dave Cridland> hartmans: Indeed. Most users have had the "use your ISPs mailserver" drummed into them.
[15:59:54] <fenton> Sam: Can't they still use a submission server corresponding to the domain?
[16:00:00] <Dave Cridland> hta: But not 587, which users are completely unaware of.
[16:00:02] <EliotLear> c=canonicalization algorithm header/body
[16:00:06] <NFreed> Actually, a lot of ISPs, including but not limited to cable providers, require use of a local MSA. Port 25 is blocked.
[16:00:09] <PaulMdx> Sam: ISPs encouraging local MTA use for non-network Froms is part of the reason we have so many spam zombies..
[16:00:09] <hartmans> If DKIM results are going to be used, network local MSAs or MUAs would need to change behavior in order to sign the mail.
[16:00:12] <Dave Cridland> fenton: They could if they knew the distinction.
[16:00:26] <EliotLear> canonicalization is meant to get around small changes in message such as header rewrapping
[16:00:28] <EliotLear> t=timestamp
[16:00:34] <EliotLear> x=expiration date
[16:00:39] <Dave Cridland> PaulMdx: I agree, but it's still the state of the art today.
[16:00:51] <EliotLear> perhaps they should be iso standard dates...
[16:00:57] <EliotLear> h=list of headers that will be signed
[16:00:59] <hta> (i gave up on submitting to my private MTA using port 25 years ago. I now submit using an ssh tunnel. only thing that works most of the time.)
[16:01:17] <Dave Cridland> hta: I find port 587 perfectly fine.
[16:01:37] <hartmans> OK. I'm very close to being convinced to blocking this until the IETF can decide what is acceptable to break.
[16:01:44] <EliotLear> <barry> h DKIM-Signature is always signed
[16:01:57] <EliotLear> <EKR> in what sense is this self signed
[16:02:09] <NFreed> Sam, you have not demonstrated that anything will break. You keep jumping around from place to place.
[16:02:13] <EliotLear> <eric allman> meta information is signed. i may be using self-signed inappropriately
[16:02:14] <mrichardson> to clarify DKIM.
[16:02:25] <mrichardson> the signature is over: from:to:subject:date:dkim-signature.
[16:02:28] <EliotLear> selector._domainkey.example.com
[16:02:34] <hta> sam: i'm not sure it breaks case 2 at all. getting through case 2 would require the signing key at the submitter.
[16:02:48] <EliotLear> <uri> what is the reason for not signing message itself.
[16:02:55] <EliotLear> <eric> the message is signed
[16:02:58] <mrichardson> the dkim-signature is canoncalized before signature, the d=asdfadsfasd;ifojewf becomes, d=;
[16:03:12] <EliotLear> how you might use DKIM
[16:03:27] <EliotLear> lets' receivers reliably apply domain-based policies
[16:03:44] <hartmans> hta: if the submitter is some random ISP and the identity is some random other company, the msa will not have the key.
[16:03:57] <hartmans> I'm fine with that so long as the IETF is willing to say that's acceptable.
[16:04:04] <EliotLear> (i get a word or two wrong, and skip stuff when i get behind)
[16:04:22] <Dave Cridland> hartmans: Well, I think the network-local situation does break, and I think the laptop-local situation also breaks, *but* I also think we should be moving to port 587, authenticated (by SASL) Submission, rather than old-skool SMTP. And you can tell your laptop to use a smarthost, authenticated etc. The trouble is, there's no single document that says that's the way things should be.
[16:04:23] <hta> sam: if the submitter is some random isp, then the submitter is not sending on behalf of the sending domain, so it IS an attack.
[16:04:25] <PaulMdx> Great job so far, Eliot.
[16:04:37] <fenton> Sam: Why wouldn't they submit to the Random Other Company then?
[16:04:48] <NFreed> Sam, in order to decide whether or not it is OK to break something, you first have to demonstrate that something will break.
[16:04:52] <EliotLear> if you end up signing legitimately as you, the check will succeed
[16:04:56] <hta> sam: you may be using "submitter" inconsistently with the smtp specs.
[16:04:57] <NFreed> You are miles away from doing that in my book.
[16:05:06] <mrichardson> Dave, that's correct-ish. but out of scope here.
[16:05:51] <EliotLear> a domain might want to sign everything so if you get an unsigned message, it's not from me
[16:06:02] <EliotLear> mark authenticated senders to end users
[16:06:05] <tonyhansen> eliot: I've been watching and haven't seen much worth correcting.
[16:06:16] <EliotLear> some of this may be best done in MUA
[16:06:24] <EliotLear> changes since -00
[16:06:34] <hartmans> hta: I assert many users use network-local msas with rfc 2822 identities that do not belong to the domain of the msa; I assert that if we are going to publish specs for which that does not work we need a community consensus that we are willing to do so.
[16:06:37] <EliotLear> - canonicalization has changed
[16:06:54] <EliotLear> nowsp is gone. relaxed is a name i made up but don't like. coauthors couldn't come up with any better
[16:07:05] <EliotLear> relaxed keeps CRLF reduces all wsp to single space
[16:07:15] <EliotLear> split selection of header and body canonicalization
[16:07:20] <NFreed> Sam, these are all common usage patterns. None of them are impacted by the use of DKIM. The DKIM base specification
[16:07:21] <EliotLear> added IANA considerations
[16:07:28] <EliotLear> Grammar bug fixes
[16:07:35] <EliotLear> Rationale
[16:07:39] <NFreed> attaches a separate identity to messages. That's all it does.
[16:07:44] <mrichardson> can there be multiple dkim-signature headers?
[16:07:49] <EliotLear> Domain owners view domains as an Asset and right now there is no way to protect against misuse
[16:08:01] <mrichardson> i.e. one from the sender, and one from the mailing list manager?
[16:08:04] <EliotLear> you need some kind of policy to know whether to accept a message or not
[16:08:13] <fenton> mrichardson: there is disagreement on whether multi signatures are a good idea.
[16:08:14] <hta> sam: are you using "msa" in the sense of the part of the MTA that accepts submission from users? In that case, the mua has to sign, end of story.
[16:08:15] <EliotLear> Core of the sender signing policy comes from SPF
[16:08:15] <NFreed> mrichardson: Good question. The handling of multiple signatures is tricky and hasn't been worked out.
[16:08:27] <tonyhansen> mrichardson: currently, yes there can be multiple signatures. debates surround it.
[16:08:29] <EliotLear> o=outbound mail polciy
[16:08:29] * hartmans will rant at the mic at an appropriate time
[16:08:45] <EliotLear> ~ domain doesn't sign all emssages
[16:08:51] <EliotLear> - does sign all messages; 3rd party
[16:08:56] <NFreed> hta: It does if it wants to participate in the use of DKIM.
[16:09:09] <EliotLear> ! domain signs all messages, no 3PS (exclusive)
[16:09:15] <EliotLear> . domain never sends mail
[16:09:36] <EliotLear> main reason is a way to truncate domain search
[16:09:43] <EliotLear> ^ check per user
[16:09:46] <EliotLear> (from i=)
[16:09:46] --- dcrocker has left: Disconnected
[16:09:55] <EliotLear> ? not all signed, no 3PS
[16:10:13] <EliotLear> does not need to be looked up if address in from field matches signing identity
[16:10:16] <tonyhansen> I'd prefer words instead of !#$%^^^ :-)
[16:10:25] <EliotLear> Mailing List
[16:10:39] <Dave Cridland> tonyhansen: Well, this is for the TXT record temporary stuff, only, I hope.
[16:10:41] <EliotLear> lists that don't break signatures. no special requirements.
[16:10:57] <patrik> sam, it is part of the design of dkim to make sure that if a random user is going to send a random email using a random msa from a random domain, the user need a user-level-key.
[16:10:57] <EliotLear> lists that break messages
[16:11:22] <tonyhansen> davec: yes I know, but we're not *that* short on space in TXT records
[16:11:29] <EliotLear> mailing list manager should probably check and resign message. it should verify incoming signatures and possibly reject bad or no signatures
[16:11:50] <EliotLear> not compatible with policies that do not allow third party signatures because from line will not match.
[16:11:59] <Dave Cridland> tonyhansen: No, but if they were readable they wouldn't be so cool, and consultancy costs would be lower.
[16:12:03] <EliotLear> we do mention multiple signatures but we don't define the semantics
[16:12:09] <EliotLear> could strip out.
[16:12:13] <EliotLear> changes
[16:12:16] <EliotLear> document restructuring
[16:12:24] <EliotLear> technical content unchanged except for 3rd party sigs
[16:12:27] <hartmans> patrik: And if you can get an ietf consensus on that and explain what will break to the community I'm happy.
[16:12:29] <EliotLear> that's it
[16:12:44] <patrik> I think people use the word "break" inconsistently. When DKIM people say "break" that in reality imply "user must behave the way they were supposed to behave from the beginning". What I hope sam is talking about when you say "break" is "people can no longer do this, regardless of how they behave".
[16:12:46] <EliotLear> <Stephen Farrell>
[16:12:47] <mrichardson> is a 3PS one in which From: != i= ?
[16:12:49] <tonyhansen> davec: you forgot the smiley :-)
[16:12:59] <fenton> mrichardson: yes
[16:13:01] <EliotLear> overivew informational RFC
[16:13:08] <NFreed> I happen to think the current SSP doc is fairly seriously flawed and needs lots of work.
[16:13:10] <EliotLear> this is for stuff that wouldn't go into the spec
[16:13:23] <EliotLear> not on critical path
[16:13:28] <Dave Cridland> tonyhansen: I'm English, I'm exempt from compulsory smileys when something is sarcastic or ironic.
[16:13:35] <tonyhansen> :-)
[16:13:38] <NFreed> But I support keeping it in scope because if we don't we'll end up with another sender-id/SPF mess.
[16:13:52] <hta> the result of policy is that the administrator of a domain can make messages that are sent today with from addresses in that domain not verify.
[16:13:55] <hartmans> I think both definitions are appropriate. I don't think we've got very good operational advice we've approved in this area.
[16:13:57] <EliotLear> there was a request that threat analysis be done before the protocols are done. so this will be an early threat analysis and then possible others
[16:13:58] <PaulMdx> Hehe, Dave.
[16:14:00] <EliotLear> looking for volunteers
[16:14:11] <EliotLear> DNS RR is not covered here but should be straight forward
[16:14:26] <hta> I don't think that's a "break". and I haven't seen anything that makes the administrator unable to permit anything he wants to permit.
[16:14:31] <patrik> sam: agreed, I just hope at the discussion we manage to separate the two cases.
[16:14:33] * mrichardson could volunteer for DNS RR specification, since he did rfc4025. Same problem. not an easy job.
[16:14:36] <EliotLear> perhaps an RFC for verficiation results to recipient. this will not happen without recharter
[16:15:07] <EliotLear> what happens if the base spec comes out and there's a problem with sha-256? maybe split out / add cypher suite specs
[16:15:26] <EliotLear> floor is open for questions.
[16:15:45] <NFreed> Fair point. DOS attacks need to be covered.
[16:15:47] <tonyhansen> doug otis: DoS isn't covered by current threat
[16:15:49] <EliotLear> again ASK: to ask a question
[16:15:52] <mrichardson> hmac-sha1 is still useable.
[16:16:19] <EliotLear> <barry> does your (doug) side draft talk about [what you can and cannot verify]
[16:16:39] <EliotLear> <doug otis> yes. also i talk about replay abuse.
[16:17:25] <EliotLear> <doug otis> SSP, there are several statements made that i think are not quite right. "you need SSP" to protect against spoofing of a bank. you're only going to add to the ability to spoof them because people are only looking at pretty names.
[16:17:45] <EliotLear> <barry> goal right now is to charter. [do we need to discuss this now]
[16:18:01] <EliotLear> <doug otis> it was presented that SSP is needed.
[16:18:17] <EliotLear> <Barry> i want you to work on SSP.
[16:18:30] <NFreed> As I have said on the list, I believe it is entirely possible that SSP will prove to be a total hairball and we
[16:18:35] <EliotLear> <doug> you're justifying the need for SSP and those justifications don't exist
[16:18:41] <EliotLear> <Stephen> let's track this through issue tracker
[16:18:47] <NFreed> will be forced to abandon.
[16:18:58] <NFreed> I wouldn't like it but it is a possibility.
[16:19:00] <EliotLear> <Jim Schaat [?]>
[16:19:22] <Dave Cridland> [Complete aside: How long before some spammer uses logging of DKIM DNS lookups to validate email addresses? Unless they already are, of course.]
[16:19:49] <EliotLear> i have some problems with dkim chartering or not. does dkim do something useful? i would find it useful if the threats document described the model. i picked up a lot from the base document.
[16:19:56] <EliotLear> <Stephen> fair point.
[16:20:14] <EliotLear> <Sam Hartman> as an IESG member, but not the responsible ad for this WG.
[16:20:24] <NFreed> Dave: How would that work? The query only includes the domain most of the time, not the local-part.
[16:20:26] <EliotLear> based on discussions today, i couldn't approve and here's why.
[16:21:00] <Dave Cridland> Depends on how many users you've sent to on the receiving MTA, doesn't it? (And what sending-domain you used).
[16:21:34] <EliotLear> i believe that it is important to consider as it will affect the internet, not just as a way of adding identity. if dkim is successful, it will encourage people to sign messages. otherwise they will get a lower class of service. so we need to look at dkim as something that will eventually be required. so it is unnacceptable to ignore Big Picture issues
[16:21:39] <NFreed> Sam's statement that it will "require users to sign email messages" is FALSE.
[16:21:59] <Dave Cridland> So if I send you a message from foo@ned-freed.spammerdomain.org, and see a lookup, then I can be reasonably sure my message got to the spam checking phase of acceptance.
[16:21:59] <NFreed> Willl someone who is there please explain this to him?
[16:22:10] <mrichardson> I agree with Sam. BUT, I think that the big picture issue needs to be researched. the big part is what Ned just wrote: "require". we can figure this out before we turn it into required.
[16:22:12] --- anewton has left
[16:22:36] <NFreed> OK, I see your point.
[16:22:37] <resnick> Ned: He's saying that if dkim is successful, people will start blacklisting on the basis of lack of dkim.
[16:22:42] <PaulMdx> Ned: Why is Sam's statement false for point 2) above?
[16:22:46] <mrichardson> Sam's point is that the issue is that people will get poorer service if they don't sign, so they will feel they should. Sort of like everyone forces me to use IE.
[16:22:48] <EliotLear> some common practices that would require changes, would be locally closed MSAs, and mailing list managers. i'm not taking a position on whether good or bad, but we need to publish a BCP on how this will impact will be felt, and that getting IETF consensus on those things they can't do because they're going to break
[16:22:54] <NFreed> Because he used the word "user".
[16:23:30] --- dkim has joined
[16:23:33] <EliotLear> <keith moore> i get the impression that there are a lot of assumption or confusion between authorship and transmission and origination of a message.
[16:23:57] <EliotLear> ... trying to relate authenticity with signal path is inherently a dubious approach.
[16:23:58] <NFreed> And later he referred to client updates being needed. This is why I insist on viewing DKIM as an MTA-level mechanism.
[16:24:21] <PaulMdx> Ok, understood.
[16:24:23] <resnick> sam: do I read you correctly as saying, "dkim's success leads to dkim's requirement and that leads to disruption of current infrastructure and that is bad"?
[16:24:29] <hartmans> We don't get to decide when this is required; mail receivers decide that.
[16:24:39] --- dkim has left
[16:24:54] <EliotLear> ... [this solution is not genera]. very difficult to sort this all. still not clear what problem they solve or how they solve any particular problem.
[16:25:04] <NFreed> Pete, in order to engage in such speculation of what will happen long-term, you also need to game the case
[16:25:08] <mrichardson> hartmans, we can say "MUST" at some point, but you are correct. the mail receivers will individually (and unilaterally) do this.
[16:25:09] <NFreed> where something like DKIM is NOT deployed.
[16:25:21] --- dumdidum has joined
[16:25:22] <resnick> eliot says at the mic:
[16:25:28] <hartmans> resnick: Not so much "and that is bad," as "and we need to commit to that change and tell the world."
[16:26:11] <resnick> reminds us of history of mime: outcome is not necessarily what we expect.
[16:26:16] <mrichardson> what elliot said.
[16:26:24] <NFreed> Bless you Eliot!
[16:26:26] <resnick> shouldn't set the bar so high that nothing gets done in an area.
[16:26:44] <resnick> Ned: That was going to be my reply.
[16:26:53] * wrs1864 agrees with Eliot also
[16:27:14] <tonyhansen> **here here**
[16:27:20] <EliotLear> <malcom cartier> i'd like to suggest that ssp be excluded from the scope as inappropriate
[16:27:51] <hartmans> I mostly agree with Eliot's comments. I actually think we need the ietf consensus up front although not the documentation.
[16:27:51] <NFreed> At this point I can live with SSP being excluded.
[16:27:54] <EliotLear> two reasons. it is about the transfer of responsibility. it's inherently flawed.
[16:28:19] <hartmans> The reason you need the consensus is that a charter is an implicit contract to accept some solution in the space and publish it.
[16:28:28] <EliotLear> ... if i tell you a lie and you are deceived by that lie you are not culpable. you are the victim. i the liar am the bad person
[16:28:34] <hartmans> So, we need a consensus to accept anything inherent in the charter at the time we charter.
[16:28:46] <EliotLear> ... what ssp is doing is placing responsibility for ascertaining the truth on the verifyer
[16:28:53] <EliotLear> .. second reason;
[16:29:01] <tonyhansen> sam: how do you propose that we could go about *getting ietf consensus* before proceeding?
[16:29:09] <EliotLear> the purpose it's being done is for the benefit of the domain owner.
[16:29:17] <NFreed> Sam, part of Eliot's point was that there is absolutely no way to know what's going to come from much of the
[16:29:19] <NFreed> work we do.
[16:29:20] * hartmans would like to see ssp included
[16:29:32] <EliotLear> it's so that you can tell me how i must act. that is not engineering, but social legislation. legal impact
[16:29:33] <NFreed> You're placing the bar impossibly high.
[16:29:37] * wrs1864 strongly wants to see SSP....
[16:29:47] --- arvel has left: Replaced by new connection
[16:29:55] <mrichardson> maybe make ssp a stretch item, and let the other stuff go forward faster.
[16:30:05] <EliotLear> <barry> not only do you disagree with the signing policy document, but we should not consider the issue at all?
[16:30:11] --- arvel has joined
[16:30:15] <EliotLear> <speaker> yes
[16:30:15] <mrichardson> that also means that without SSP it might not be so popular, so won't encounter the other problems that Sam suggests.
[16:30:34] --- dkim has joined
[16:30:59] <arvel> Eliot: the BoF folk wanted their statement read as if they were on Jabber. Can you do that?
[16:31:07] <EliotLear> <speaker> with respect to the big picture, we must consider the big picture. it's quite wrong to say that you must act in a particular way. i want to be able to make assertions about me, but that you must take account is legal and social policy
[16:31:10] <arvel> BoA folk - sorry
[16:31:18] <EliotLear> <stephen> there's disagreement
[16:32:14] <EliotLear> <dave crocker> DKIM does have a problem and we haven't figured out how to fix it. DKIM is a small discrete mechanism. it adds an identity that you can use.
[16:33:15] <EliotLear> the problem is that DKIM has lots of potential that scares the **** out of us. we understand the concept of unintended consequences and so things can go wrong. there is guaranteed to be something we don't want for such a large system. please read what eliot said [we can set the bar impossibly high]
[16:34:05] <EliotLear> <keith moore> the problem dkim is that it doesn't mean anything useful. this is not the problem most people want to solve. they want to solve spam, phishing, virus... dkim doesn't do that.
[16:34:34] <EliotLear> ... a lot of people think dkim does something close to useful, but it has a lot of potential to encourage confusion than a useful result.
[16:34:46] <EliotLear> <barry> is there use in "i signed this. please white list me."
[16:35:18] <EliotLear> <keith> i believe it's useful for authors to give domains a way to sign messages such that recipients could verify..
[16:35:28] <EliotLear> [someone please check me on that]
[16:35:37] <EliotLear> [in terms of keith's wording]
[16:35:58] <NFreed> Eliot, I think Keith is talking about author signatures.
[16:36:06] <Dave Cridland> Hmmm... I sat through Paris and nearly all of this, and now I've suddenly got what Keith's saying.
[16:36:18] <EliotLear> <keith> to respond to what eliot said... i remember that time. we originally wanted to do an 8 bit extension, and the idea of attachments wasn't in there...
[16:36:26] --- jeaton has left
[16:37:07] <EliotLear> ... if by chartering a group like dkim we were able to get a discussion going that would get a real solution going, i'm all for that, but the problem is that we can't get a working group formed without a concrete solution, and then we're sort of stuck with that.
[16:37:11] --- dcrocker has joined
[16:37:29] <EliotLear> dkim is [a good starting point] but we should not constrain ourselves to dkim
[16:37:38] <EliotLear> <pete resnick> not speaking for the ietf.
[16:37:46] <EliotLear> dkim doesn'
[16:37:48] <EliotLear> <pete> not speaking for the iab
[16:38:29] <EliotLear> dkim doesn't purport anything. dkim is a mechanism. we should get away from trying to judge dkim as to what dkim would be useful for 20 years for now. if you can see that it is useful to solve some small problem today, that's enough.
[16:38:32] <NFreed> Pete is of course correct. Our crystal ball has never worked very well.
[16:39:20] <EliotLear> that said, listening to sam, part of the problem he sees that dkim once deployed might require folks to use it. therefore, a potential disruption to the infrastructure is in and of itself Bad.
[16:39:26] <Dave Cridland> The interesting bit of what Keith said was essentially that if SMIME worked, there'd be no need for DKIM. So we need to look at *why* SMIME doesn't work, and possibly even how to make it work.
[16:39:29] <arvel> any change has that potential - so is this an argument for doing nothing?
[16:39:39] <NFreed> Bingo!
[16:39:43] <EliotLear> but we also need to look at the current disruption of the infrastructure
[16:39:50] <mrichardson> Dave, S/MIME wasn't deployable to the masses easily.
[16:40:12] <EliotLear> we need to measure those two things and [make a judgment] as to whether [things will be better or worse]
[16:40:17] <Dave Cridland> mrichardson: Indeed not. Which is why I'm inclined to agree wholeheartedly with Keith.
[16:40:18] <NFreed> Dave: And what happens when the reasons S/MIME doesn't work turn out not to be fixable, at least not
[16:40:23] <dcrocker> arvel -- yes. and now that we've settled that, we can go get that beer.
[16:40:25] <NFreed> in any way the IETF has control over?
[16:40:32] <EliotLear> <sam hartman> please include SSP if we charter
[16:40:35] <arvel> lol
[16:40:38] <Dave Cridland> Ned: Then we need something better that *does* work.
[16:40:38] <mrichardson> I am flabbergasted that Bank of America can't buy a PC that runs IE, hire a consultant at $1000/day (for 1 day), to call up verisign and get a S/MIME certificate. SHEESH.
[16:41:01] <PaulMdx> Hehe.
[16:41:20] <EliotLear> ... i would like to agree with pete. all i was saying was that we need to commit to that potential the change and document the change in the class of service that might result. not saying that it was unacceptable bad.
[16:41:34] <EliotLear> Russ: i'm concerned about [doing the BCP prior to charter]
[16:41:38] <mrichardson> Outlook/IE does S/MIME. Many organizations won't let you run anything other than Outlook because it supports S/MIME, and then... NEVER USE S/MIME.
[16:41:39] <wrs1864> mrichardson: S/MIME breaks in too many cases...
[16:41:39] <NFreed> Well, I can't speak to other experiences, but we have some very large S/MIME deployments - on the order
[16:41:39] <EliotLear> <Jim Fenton>
[16:41:40] <NFreed> of millions of users.
[16:41:54] <Dave Cridland> dcrocker: Do I recall right that you had a draft out at some point giving a broad overview of the internet mail architecture?
[16:42:04] <mrichardson> wrs1864, you can point me at the list privately.
[16:42:06] <EliotLear> there isn't anything in the dkim specs that mandates any behavior. this includes SSP.
[16:42:24] <NFreed> The problem with more general use of S/MIME, or any similar technology, I fear are insoluable.
[16:42:43] <EliotLear> maybe you know something about the signing address, maybe you don't and a large body of unsigned address, and what the alleged sender would like you to do with those unsigned messages.
[16:42:59] <EliotLear> <Stephen> without policy unsigned mail be hard to deal with
[16:43:00] <dcrocker> from Dave C to Dave C: yes. Take a look at bbiw.net for a copy.
[16:43:22] <Dave Cridland> dcrocker: Only I was saying a little while ago that we really need one.
[16:43:32] <EliotLear> <Harald> i haven't read the drafts but i've been listening to the discussion and i was trying to put myself in the shoes of someone who brings work to the ietf and is less polite.
[16:44:24] <NFreed> People, you need to pay attention to what Harald is saying.
[16:44:30] <EliotLear> ... if i was told that i was going to have to have consensus on something that might or might not occur 10 years out i would walk away
[16:44:40] <dcrocker> CLOSE attention to what he is saying
[16:44:59] <EliotLear> ... this discussion is about whether the IETF will be allowed to contribute to this effort. the ietf may not have input
[16:45:01] <NFreed> Clap clap clap
[16:45:10] <EliotLear> <Jim>
[16:45:16] <EliotLear> <Jim Gavin>
[16:45:23] <NFreed> That's Galvin.
[16:45:59] <EliotLear> it says that mailing lists break sigs and dkim. that's an unfair characterization. mailing list managers are good actors. you just need to tell them what the right thing to do is.
[16:46:44] <EliotLear> as far as no 3PS and mailing list managers, this gets to the point that sam was discussing.
[16:46:50] <hta> the ietf mailing list still breaks my PGP/MIME signatures part of the time. about 5 years after I reported the bug the first time. I think it has been traced to a bug in the Python mail-parsing library......
[16:47:15] <EliotLear> <Stephen, Barry> in scope
[16:47:22] <EliotLear> (Jim's point that is)
[16:47:48] --- cnewman has joined
[16:47:48] <EliotLear> <Doug Otis> base spec provides basis for a good mechanism. SSP does talk about good and bad behavior.
[16:47:52] <dcrocker> hta - i assume that means that you need to get the pythons standards group to change things, to cover this problem?
[16:48:39] <EliotLear> the vast majority of people would not want to be as restrictive as a bank, and so i think we want to figure out how to special case the bank and [optimize for the general case].
[16:48:51] <EliotLear> <Barry> come to WG meetings and help us work that out.
[16:49:29] <hta> dcrocker: I have no idea where to start on that, and that's a problem...... I know there's a bug filed on the python bugzilla on this topic (I once managed to find it), but I don't know where to go in order to change the priorities of the Python developers to go fix it....
[16:49:52] <EliotLear> <Keith Moore> in resposne to harald, it's really easy to say that dkim is really simple. over the years we've seen lots of simple proposals that we thought wouldn't have unintended consequences.
[16:50:23] <dcrocker> hta -- hmmm. i was being facetious, but perhaps not facetious (or obvious) enough.
[16:50:41] <EliotLear> <Barry> he didn't say that we shouldn't consider unintended consequences, but that we should do that in the WG
[16:50:58] <EliotLear> <Keith> [i like sam's approach]
[16:51:17] <EliotLear> line closed.
[16:51:28] <hta> dave: it's a classic of "there is a simple problem, but when you start pulling on it, the thread disappears out of your control"......
[16:51:41] <hta> many standards things are like that too.
[16:51:55] <EliotLear> <Bill Sommerfeld> similar comment to Jim Galvin. i think the charter should [specifically address] mailing lists
[16:52:11] <EliotLear> needs to be covered in the output
[16:52:22] <EliotLear> <Mark Delany>
[16:52:27] <mrichardson> it should be a seperate document, so that we can point people at "RFCXXXX", and show that clueless people can put that into their RFP.
[16:52:43] <EliotLear> i'd like to put a vote in for SSP in some form, perhaps not necessarily this form.
[16:52:54] <EliotLear> example: ebay wants to be able to control who can represent them
[16:53:35] <EliotLear> <name lost> agree with harald. every possible protocol we develop could have unintended consequences.
[16:53:51] --- arvel has left: Replaced by new connection
[16:53:56] <patrik> Richard Shockey was the one making the statement
[16:54:02] --- arvel has joined
[16:54:08] <EliotLear> <bernard> biggest problem is unintended consequences come from things that are useful not things that are not useful
[16:54:10] <resnick> Now Bernard Aboba is talking
[16:54:15] <EliotLear> [thanks, patrik]
[16:54:35] <EliotLear> <Barry Leiba> hmms...
[16:54:39] <dcrocker> hta -- yeah. i guess the problem is that the truth of the thread model can be used to seriously force infinite study, or it can be used to highlight the absurdity of worrying about a possible thread unraveling sometime in the unknown future. (and this all sounds far more serious than i meant to be.)
[16:54:55] <EliotLear> <barry> how does the iesg decide about hmm. today?
[16:55:01] <EliotLear> <russ> next step community review
[16:55:15] <wrs1864> Hmmmmm
[16:55:19] <Dave Cridland> dcrocker: And recall that multithreading always makes things much more complex...
[16:55:19] <EliotLear> how many think a WG should be chartered?
[16:55:20] <NFreed> Hmmmm
[16:55:23] <PaulMdx> Hmmmm
[16:55:26] --- dcrocker has left
[16:55:28] <EliotLear> many hmms. in favor
[16:55:28] <Dave Cridland> I'm humming for chartering, BTW.
[16:55:32] <EliotLear> few opposed
[16:55:33] <NFreed> Me too!
[16:55:36] --- kmurchison has left
[16:55:38] <PaulMdx> Ditto.
[16:55:40] --- lha has left
[16:55:42] <EliotLear> we are concluded. good day
[16:55:47] <arvel> excellent all
[16:55:48] --- EliotLear has left
[16:55:50] --- Melinda has left
[16:55:51] <joshlitt> Thanks Eliott
[16:55:52] --- hartmans has left
[16:55:59] --- kivinen has left
[16:55:59] --- resnick has left
[16:56:00] --- arvel has left
[16:56:03] --- PaulMdx has left
[16:56:04] <Dave Cridland> eliot: nice job.
[16:56:04] --- fenton has left
[16:56:05] <tonyhansen> ta ta all
[16:56:06] * wrs1864 hopes things go forward this time.
[16:56:06] --- jimsch has left
[16:56:15] --- Dave Cridland has left
[16:56:18] --- joshlitt has left
[16:56:25] <NFreed> ttfn
[16:56:28] --- NFreed has left
[16:56:37] <hta> bye folks!
[16:56:39] --- patrik has left
[16:56:40] --- hta has left
[16:56:42] --- cnewman has left
[16:57:14] --- eric has left: Disconnected
[17:11:54] --- dumdidum has left: Replaced by new connection
[17:16:02] --- hardie@qualcomm.com has left: Replaced by new connection.
[17:16:13] --- tonyhansen has left: Replaced by new connection
[17:22:38] --- mrichardson has left
[19:27:30] --- dkim has left: Disconnected
[19:47:53] --- wrs1864 has left
[19:52:21] --- wrs1864 has joined
[19:52:50] --- wrs1864 has left
[20:32:26] --- dcrocker has joined
[20:38:30] --- dcrocker has left
[21:59:42] --- adaviel has joined
[22:01:35] --- adaviel has left