[08:07:24] --- sftcd has joined
[08:07:36] <sftcd> No-one else here yet?
[08:30:09] --- wildcat has joined
[08:30:20] <wildcat> Hello
[08:30:48] <sftcd> Hi, who's that then (this is stephen farrell)
[08:31:04] <wildcat> Its the guy people like to ignore <g>
[08:31:26] <sftcd> Hmmm...
[08:31:50] <wildcat> Its hector, Stephen. This is my first jabber-style chat.
[08:32:15] <sftcd> I figured. Well you're up and running. I won't chat too much -marking exam papers at the 'mo
[08:32:18] <sftcd> talk to you later
[08:32:24] <wildcat> see ya
[08:33:23] <wildcat> help
[08:33:55] <sftcd> huh? no help here! Encouragement maybe:-)
[08:34:07] <wildcat> I found the /help.
[08:34:50] <wildcat> how is this chat going to be structured?
[08:35:19] <sftcd> good question - this is a 1st (for the IETF afaik) so we'll have to suck it and see
[08:35:23] <sftcd> hence the 1-item agenda
[08:37:02] <wildcat> I'm going to have to investigate adding jabber to our intranet IM system. Looks interesting.
[08:41:04] * wildcat has changed the subject to: DKIM
[08:41:15] <wildcat> Hehehe <g>
[08:43:03] * sftcd has set the topic to: DKIM - premeeting
[08:43:45] <sftcd> Good idea:-)
[08:44:37] <wildcat> Where's the open bar?
[09:05:01] --- wildcat is now known as hls
[09:05:31] --- hls is now known as wildcat
[09:07:02] --- wildcat has left
[09:07:19] --- wildcat has joined
[09:09:28] --- wildcat has left
[09:13:42] --- wildcat has joined
[09:13:45] --- wildcat has left
[09:13:49] --- wildcat has joined
[09:22:50] --- arvel has joined
[09:23:40] --- wildcat is now known as santosh
[09:23:54] <santosh> Hello Arvel
[09:24:06] --- arvel has left
[09:24:12] --- arvel has joined
[09:24:19] <arvel> hi there
[09:24:37] <santosh> Looks like up/running. :-)
[09:24:40] <arvel> I think I'm a bit early but just checking out my config
[09:26:19] --- santosh is now known as wildcat
[09:26:23] <sftcd> Hi arvel, you're coming in loud and clear
[09:34:32] <arvel> cool. I think the meeting is in about 1 hour or so from now?
[09:34:35] <arvel> or is it two?
[09:35:06] --- wildcat has left
[09:37:10] --- wildcat has joined
[09:38:53] <wildcat> 11 EST MIAMI time. I think. You are in San Antonio, Texas? 10?
[09:39:44] <arvel> Actually, I'm in Chicago at the moment for the MS Summit thing they had yesterday - normally I'd be in Dallas.
[09:40:10] <arvel> It's going to be 10am here in Chicago then (the start time that is)
[09:43:02] --- wildcat has left
[09:43:44] --- wildcat has joined
[09:45:47] --- arvel has left
[09:51:12] --- wildcat has left
[10:01:27] * sftcd has set the topic to: DKIM - meetin in one hour
[10:06:51] --- Paul Hoffman has joined
[10:07:26] <Paul Hoffman> G'morning y'all.
[10:10:03] <sftcd> hi paul
[10:10:46] <Paul Hoffman> I forgot if I suggested this earlier, but you should see if your Jabber client lets you put an alias in. No one is going to figure out sftcd...
[10:11:16] <sftcd> yerra they'll get used to it (and I'll 'fess up at the start)
[10:11:33] <sftcd> and its in the logs
[10:21:16] * sftcd has set the topic to: DKIM - meeting in 40 miins
[10:31:59] --- wildcat has joined
[10:32:36] --- wildcat is now known as Hector Santos
[10:40:16] * sftcd has set the topic to: DKIM - meeting in 20 miins
[10:41:47] --- fenton has joined
[10:43:55] --- Barry Leiba has joined
[10:44:09] <Barry Leiba> Y'all're early.
[10:44:40] <fenton> aww, do we need to leave and come back in?
[10:45:24] <Barry Leiba> Stephen, what jabber client are you using?
[10:46:08] <sftcd> hiya - I'm using psi
[10:46:26] <Barry Leiba> I think Psi lets you set your nickname.
[10:46:50] <sftcd> sure - but do I know how? anyway it is me:-0
[10:46:55] <Barry Leiba> In fact, I know it does, 'cause when I use it I show up as "Barry Leiba" (as I am now with Exodus).
[10:47:14] <Hector Santos> Right Click for me with Exodus allows Nickname change
[10:50:52] --- doug_trendmicro@jabber.org has joined
[10:50:59] --- pk has joined
[10:52:01] * sftcd has set the topic to: DKIM - meeting in 10 miins
[10:52:12] * sftcd has set the topic to: DKIM - meeting in 10
[10:53:26] * sftcd has set the topic to: DKIM - meeting in 10
[10:54:09] <doug_trendmicro@jabber.org> Does PSI allow the use of passwords?
[10:54:22] * sftcd has set the topic to: DKIM - meeting soon
[10:56:10] --- pk has left
[10:56:30] <fenton> hello? Has my client crashed?
[10:56:37] --- fenton has left
[10:57:05] --- sftcd has left
[10:57:38] --- sftcd has joined
[10:57:48] --- arvel has joined
[10:58:05] --- arvel has left
[10:58:27] --- arvel has joined
[10:58:29] --- Jim Fenton has joined
[10:58:59] --- arvel has left
[10:58:59] <Barry Leiba> ?
[10:59:13] --- sftcd has left
[10:59:27] --- Barry Leiba has left
[10:59:32] --- pk has joined
[10:59:37] --- Barry Leiba has joined
[11:00:02] --- arvel has joined
[11:00:46] --- sftcd has joined
[11:00:49] <Paul Hoffman> My clock say 8:00
[11:00:55] --- arvel has left
[11:01:41] --- hallam has joined
[11:01:55] <hallam> Mine says 11:00
[11:02:14] --- sftcd has left
[11:02:25] --- pk has left
[11:02:29] --- arvel has joined
[11:02:33] <Paul Hoffman> Helllloooo?
[11:02:42] --- arvel has left
[11:03:04] --- pk has joined
[11:03:11] --- Paul Hoffman has left: Logged out
[11:03:29] <hallam> Does anyone have the agenda?
[11:04:24] --- arvel has joined
[11:04:24] --- pk has left
[11:04:26] --- arvel has left
[11:04:38] --- pk has joined
[11:04:39] --- sftcd has joined
[11:04:42] --- Paul Hoffman has joined
[11:04:50] --- sftcd has left
[11:05:02] --- pk has left
[11:05:41] --- paulehoffman has joined
[11:05:48] --- Peter Koch has joined
[11:06:09] <Jim Fenton> Are we back in business here?
[11:06:23] <paulehoffman> No, things look very messed up.
[11:06:43] --- Hector Santos has left
[11:06:45] --- wildcat has joined
[11:06:46] <hallam> It seems to be working with exodus
[11:07:06] <paulehoffman> For example, I don't see Jim or Phill on the participant list, even though they are posting.
[11:07:07] <hallam> Is there a connection limit?
[11:07:19] --- arvel has joined
[11:07:26] <hallam> People seem to be entering and leaving all the time
[11:07:35] <Jim Fenton> I only see 3 participants: Paul, Hector, and Peter...and now Arvel
[11:07:50] <paulehoffman> Right, even though Phill just posted.
[11:07:53] <doug_trendmicro@jabber.org> I see 9
[11:08:04] <arvel> I've got 9 here too
[11:08:06] <wildcat> Paul, I see two instances for you, Paul Hoffman and paulehoffman
[11:08:15] --- paulehoffman has left
[11:08:25] <hallam> Arvel, have you been having difficulty connecting?
[11:08:29] <Paul Hoffman> I was trying a second Jabber client to see what was up.
[11:08:44] <arvel> yes but it worked finally
[11:08:45] --- wildcat is now known as Hector Santos
[11:08:53] <Jim Fenton> I'm trying with Gaim and Exodus on different machines, and having trouble with both.
[11:08:57] <Paul Hoffman> I take it that neither Barry nor Stephen are still on the chat for some reason?
[11:09:12] <Jim Fenton> Barry is trying to connect and having trouble
[11:09:40] <doug_trendmicro@jabber.org> I still see both of them.
[11:09:53] <doug_trendmicro@jabber.org> sftcd = stephen
[11:10:38] <Barry Leiba> Things are weird. I see only myself in the roster, and no old messages, but I just saw Doug's message about "sftcd = stephen".
[11:10:46] <Paul Hoffman> I see Barry now, but not Stephen. Which is odd, because Stephen is taller than Barry.
[11:10:47] <Barry Leiba> Who else is here, and getting my messages?
[11:10:57] <Jim Fenton> fenton
[11:11:01] <arvel> lol
[11:11:02] <Paul Hoffman> Hoffman
[11:11:03] <Hector Santos> I do.
[11:11:16] <Peter Koch> i see Barry
[11:11:19] <arvel> I see Barry also
[11:11:26] --- sftcd has joined
[11:11:37] <Barry Leiba> I just saw Stephen come on.
[11:11:38] <sftcd> whee hee!
[11:11:49] <sftcd> let's give it 10 to stabilise
[11:11:55] <Hector Santos> 9 total here
[11:12:28] <sftcd> yes, the following was the last logline before the problem "Does PSI allow the use of passwords?" I wonder...
[11:12:28] <hallam> This technology does not appear ready for prime time
[11:12:47] <Barry Leiba> My roster still only shows me and Stephen, though, even though I'm getting messages from others. I have messages from Paul, Jim, Hector, Peter, Doug, Arvel. I see myself and Stephen in the roster. Hector says there's one more. ┬┐Quien?
[11:12:47] <arvel> ha ha
[11:12:51] <Barry Leiba> Ah, Phill.
[11:13:08] <doug_trendmicro@jabber.org> doug/paul/sftcd/barry/fenton/peter/wildcat/arvel are all I see?
[11:13:16] <Paul Hoffman> So, let's assume that it's working but the roster is messed up.
[11:13:21] <Hector Santos> I see, arvel, barr, doug, hallam, me, jim, paul, peter, stfcd
[11:14:17] <sftcd> the systems guys says some people are trying the old room name
[11:14:25] <sftcd> I sent a mail to the list
[11:14:35] <Hector Santos> Wildcat was my default nick. I had switch it via the chat window.
[11:15:43] <Hector Santos> Gee, I feel like a kid again <g>
[11:16:07] <arvel> it's nice to see some of you in a legitimate chat room for a change - lol
[11:16:30] <sftcd> ok, given the problems we'll start at half-past, in 14 mins or so
[11:16:35] <Barry Leiba> OK, looks like we'll have to have a much shorter meeting, but let's plan to start work at xx:30, which, with any luck, will give people more time.
[11:16:42] <Barry Leiba> to get on.
[11:16:43] <Hector Santos> where's the open bar?
[11:16:53] <Barry Leiba> Ah, Stephen and I said the same thing.
[11:17:22] <sftcd> FYI meeting logs are at: http://www.ietf.org/meetings/ietf-logs/dkim/2006-04-20.html
[11:17:39] <sftcd> And the agenda and rules-of-the-road are at: http://mipassoc.org/pipermail/ietf-dkim/2006q2/003406.html
[11:18:03] --- Jim Fenton has left
[11:18:18] --- Jim Fenton has joined
[11:23:14] <Paul Hoffman> *twiddles thumbs*
[11:23:41] <Jim Fenton> Thanks Paul, I hadn't seen a posting in a new min and I was wondering if the room problems had reemerged.
[11:23:41] <sftcd> are you good at that?
[11:24:20] <Paul Hoffman> No, I mostly posted that because I wanted to see if the chat was still alive.
[11:24:44] <Barry Leiba> Stephen could sing, instead.
[11:24:52] * sftcd has set the topic to: DKIM - meeting starts in 5 - take your seats
[11:25:03] <sftcd> stephen never signs (sober)
[11:25:05] <Jim Fenton> With this group, when it gets quiet is usually like when your kids get too quiet...
[11:25:05] <Barry Leiba> (Actually, I was at an Irish pub in NY last night, listening to fiddling and singing.)
[11:25:35] <Barry Leiba> "Sober" is why the music session was at a pub.
[11:26:19] <sftcd> I'll try that tonight so.
[11:26:51] <Hector Santos> I want to switch over to my laptop but I've been lucky so far without problems. :-)
[11:27:02] <Barry Leiba> If it ain't broke....
[11:28:19] <Barry Leiba> 2 minutes...
[11:28:47] <sftcd> amazing how we've all lost confidence in jabber, wonder how long it'll take to get it back?
[11:29:26] <Hector Santos> Server problems?
[11:29:40] <doug_trendmicro@jabber.org> Should there a ping requested to see who is really here?
[11:29:57] <Barry Leiba> Has anyone joined besides these?:
[11:29:58] --- spirzada has joined
[11:30:08] <sftcd> Ok, let's start
[11:30:14] <Hector Santos> I see #10
[11:30:20] <sftcd> The agenda is:
[11:30:26] <sftcd> 1. Agenda bashing
[11:30:33] <sftcd> 2. Finialise text for x=
[11:30:35] <sftcd> 3. AOB
[11:30:40] <Barry Leiba> Paul, Phill, Barry, Stephen, Jim, Hector, Doug, Arvel
[11:30:44] * sftcd has set the topic to: DKIM - meeting starrted - agenda bashing
[11:30:56] <Barry Leiba> I see that spirzada just joined.
[11:30:59] <Barry Leiba> Is there one other?
[11:31:03] --- ogud has joined
[11:31:10] <Hector Santos> #11 ogud
[11:31:13] <doug_trendmicro@jabber.org> Is there time to talk about 5.2 7days?
[11:31:13] <sftcd> we're at 1. any comments?
[11:31:20] <Paul Hoffman> Who is spirzada?
[11:31:26] <sftcd> in AOB doug
[11:31:40] <Barry Leiba> On and Peter Koch is on too.
[11:31:50] <Jim Fenton> spirzada = Shamim Pirzada, one of my co-workers
[11:31:51] <sftcd> ok, no others so let's move on to item 2.
[11:31:51] <Barry Leiba> Who are ogud and spirzada?
[11:32:13] <sftcd> My strawman is at: http://mipassoc.org/pipermail/ietf-dkim/2006q2/003378.html
[11:32:28] <Paul Hoffman> *raises hand*
[11:32:29] <Barry Leiba> Right... so...
[11:32:33] <Barry Leiba> Paul.
[11:33:13] <Paul Hoffman> I think it is really important that we follow 2119. Thus, I would like to hear why people think the receiver SHOULD implement expiring.
[11:33:24] <Paul Hoffman> EOM
[11:33:39] <Barry Leiba> Open for comments.
[11:33:51] <arvel> MAY is probably better in this case I guess
[11:33:59] <ogud> ogud == Olafur Gudumundsson
[11:34:02] <arvel> over
[11:34:06] <Barry Leiba> Thanks Olafur.
[11:34:16] <sftcd> (as a participant) I agree with Arvel, put SHOULD in strawman cause I thought that was wanted, not cause I wanted it
[11:34:32] <Barry Leiba> As a participant, I, too, agree with MAY.
[11:34:48] <sftcd> Anyone disagree with MAY for x= then? (modulo confirmation on list)
[11:34:48] <Barry Leiba> As I see it, there are two reasons to use SHOULD:
[11:34:51] <Hector Santos> I agree with MAY support, but if supported, MUST HONOR
[11:35:09] <Barry Leiba> 1. It helps interoperability,
[11:35:24] <doug_trendmicro@jabber.org> SHOULD not implement x=, but MAY reject is really bad.
[11:35:36] <Barry Leiba> 2. It's required for understanding what the signer wants.
[11:35:51] <Paul Hoffman> Barry, could you say where you see it helps on interop? I don't see it.
[11:35:54] <Barry Leiba> Hector, why do you want MUST?
[11:36:08] <sftcd> Hector wants a contingent MUST.
[11:36:15] <Barry Leiba> Paul, I didn't say it helps interop... I said that WOULD be a reason to have SHOULD/MUST.
[11:36:25] <Barry Leiba> I agree that I don't see it either, which is why I support MAY.
[11:36:25] <sftcd> I think he said MAY implement, if implement MUST do it this way...
[11:36:34] <Paul Hoffman> Ah, sorry, misunderstood. Thanks.
[11:36:43] <Barry Leiba> I understand what Hector said; I'm asking why.
[11:37:23] <Hector Santos> I think enforcement is important, forcing the domain desire. To ignore it, raises issues.
[11:37:25] <doug_trendmicro@jabber.org> Why is it required to understand signature expiry?
[11:37:27] <arvel> What would be the point of implementing x= if you didn't honor it?
[11:37:38] <Paul Hoffman> To me, x= is a request from the signer. The recipient may respond to that request however he/she wants.
[11:37:55] <Paul Hoffman> Some recipients want to honor the signer's request.
[11:38:02] <Barry Leiba> I'm groping here, but thinking that there might be a reason a verifier would want to use different behaviour here for different signers with different reputations.
[11:38:09] <Barry Leiba> Maybe that's silly, though.
[11:38:12] <Paul Hoffman> But I think that will be very few in this case.
[11:38:18] <Hector Santos> I agree with Paul, if it remains completely policy driven, not technical with a MAY support, MAY HONOR
[11:38:24] <hallam> There is a big difference in the protocol behavior and forensics
[11:38:37] <sftcd> analagous to best-before-date on a milk carton - if I've
[11:38:42] <hallam> x= is totaly irrelevant if we are talking about forensics
[11:38:47] <sftcd> no other milk I'll try old stuff
[11:39:01] <doug_trendmicro@jabber.org> If x= causes a rejection a some MTAs and not at others, that can create a serious DSN problem.
[11:39:02] <Barry Leiba> Phill, I don't think the x= argument is for forensics, though.
[11:39:04] <hallam> x=can have protocol relevance, affect client behavior
[11:39:31] <hallam> People are arguing to exclude use cases that are essentially forensic
[11:39:39] <hallam> Reputation engines are forensic
[11:39:43] <Jim Fenton> Stephen: Is is fair to take your "best before" analogy further and say "Don't be surprised if it's sour"?
[11:39:43] <Barry Leiba> Hector, do I understand that you're now OK with MAY entirely?
[11:40:13] <Hector Santos> Yes
[11:40:16] <Barry Leiba> Phill, are you arguing for something stronger than MAY?
[11:40:16] <hallam> I like Jim's analogy
[11:40:18] <Paul Hoffman> Phill, having a MAY on the verifier doesn't exclude any use cases, does it?
[11:40:24] <sftcd> Jim: sure
[11:40:33] <hallam> I think MAY on both sides is appropriate
[11:40:51] <Barry Leiba> OK. I hear MAY everywhere. 15 seconds to refute......
[11:40:57] <arvel> Phil: so do I and "sour" can mean that the key isn't there anymore in DNS - that would be rancid actually - he he
[11:41:14] <Barry Leiba> No refutations. The MAYs have it.
[11:41:23] <Barry Leiba> Other comments on the proposed text?
[11:41:38] <Paul Hoffman> Comment: there are a bunch of misspellings.
[11:41:43] <arvel> one thing but it's hard to write out... sec
[11:41:44] <Hector Santos> Its all good here. :-)
[11:41:46] <Barry Leiba> 's cause he's Irish.
[11:41:55] <sftcd> I can take the action to add MAY everywhere unless someone else wants it...
[11:42:05] <sftcd> or maybe I'll add MYA
[11:42:11] <Paul Hoffman> Go for it, Stephen.
[11:42:19] <Jim Fenton> With the analogy, I'm concerned that some people want to interpret x= as "MUST NOT taste as it may be poisonous" and others as "MAY taste, but SHOULD NOT be surprised if it's sour".
[11:42:26] <arvel> the old text mentioned that an expired sig "must not be considered valid" but the new text says "must be considered as crytographically failed" (or similar)... (more)
[11:42:46] <arvel> manta 1 is that a broken sig is the same as no sig so this isn't a problem is it?
[11:42:48] <doug_trendmicro@jabber.org> How are DSN handled when there are differing standards?
[11:43:06] <Paul Hoffman> Doug, this has nothing to do with DSNs.
[11:43:06] <Barry Leiba> I think our intent with the proposed text was...
[11:43:24] <sftcd> Agree with Paul. Don't see how DSN is here
[11:43:42] <doug_trendmicro@jabber.org> Changing the status of the signature may result in rejections depending upon sender policy.
[11:43:42] <Barry Leiba> expired sig == broken sig... and the rest of the spec says you should treat broken the same as absent.
[11:43:53] <arvel> Barry: ok got it
[11:44:10] <Barry Leiba> Should the wording be changed to clarify that in some way?
[11:44:50] <Hector Santos> I have a problem with the "Broken = Absent" concept because it isn't true :-)
[11:44:54] <sftcd> Answering Jim: the latter, MAY taste, ...
[11:44:56] <arvel> Maybe we could use some explicit text here saying that an expired sig should be treated as if it weren't there rather than saying that it "cryto fails" etc?
[11:45:06] <Paul Hoffman> Doug, that is an SSP issue, not a -base issue.
[11:45:08] <Barry Leiba> Doug: verifier will decide how to handle the message (discard, reject, filter, whatever). DKIM is only concerned with the mechanics of verifying, not with what the verifier does after.
[11:45:27] <sftcd> Hector: that's a global problem (if it is one) though and not x= specific
[11:45:36] <Barry Leiba> Hector...
[11:45:43] <doug_trendmicro@jabber.org> DKIM should attempt to ensure all MTAs see the message the same.
[11:45:46] * sftcd has set the topic to: DKIM - meeting starrted - forgot to say we're on item 2
[11:45:58] <Barry Leiba> I agree that not everyone will want to *actually* treat broken == absent. But...
[11:46:02] <arvel> The new text says to treat the expired as if crytographic checking had failed or the public key were not retrievable. Seems easier just to say ignore expired sigs.
[11:46:32] <sftcd> Arvel - I'd have no problem with that. Was just trying to hammer it home in the strawman
[11:46:42] <Barry Leiba> If broken is worse than absent, then attackers will remove sigs, making the distinction useless.
[11:46:43] <Jim Fenton> But the "MAY taste" concept says that you can use it if it still verifies, which is a very different rule.
[11:47:02] <arvel> Barry: yes that's right
[11:47:05] <Barry Leiba> If absent is worse than broken, then spammers/phishers will add fake sigs that come out as broken.
[11:47:15] <Barry Leiba> Therefore, the spec says to treat them the same.
[11:47:27] <sftcd> Jim: Isn't that a consequence of local policy trumping everything else?
[11:47:29] <Paul Hoffman> The current text says "Verifiers who support x= MUST conside a signatuure invalid if the current time at the verifier is past the expiration date. If a signature is invalid for this reason, then the normal rules apply, so the signature SHOULD be treated the same as if cryptographic checking had failed or as if the public key could not be retrieved." I propose removing the second sentence and putting that idea out in the main body.
[11:47:34] <Hector Santos> I think in practice it might mean "check the next trick you have" but I understand your point. I just think that giving....
[11:48:18] <Hector Santos> the evidence that a verifier will see in his logs, he might be scratching his head why nothing is being done about it. Any who, I don't htink we need to talk about that. Right?>
[11:48:21] <Paul Hoffman> That is, to say "all invalid signatures should be treated as ..." somewhere before section 3.5
[11:48:23] <Jim Fenton> Stephen: It is, it's just not clear to me what the requirements are for a "compliant" verifier
[11:48:25] <Barry Leiba> Let me bring up one thing I saw in the mailing-list discussion.
[11:48:29] <sftcd> I can follow Paul's instruction there unless someone says not to...
[11:49:15] <Barry Leiba> There seemed to be disagreement about whether crossing the x= time ought to make you FORGET about a previous validation.
[11:49:27] <Paul Hoffman> Jim: a compliant verifier MAY consider the signature invalid. That's completely clear to me.
[11:49:27] <Barry Leiba> I don't think anyone was really advocating this. Does anyone think anyone was?
[11:49:53] <Paul Hoffman> Barry: Stephen's current wording precludes that.
[11:49:53] <doug_trendmicro@jabber.org> Can you change current time to received time.
[11:50:16] <Barry Leiba> Paul: I agree. Just making sure that no one thinks we should be doing that.
[11:50:21] <Jim Fenton> how about verification time
[11:50:22] <Paul Hoffman> "Verifiers who support x= MUST conside a signatuure invalid if the current time at the verifier is past the expiration date." That is done at the time of verification, not at the time of reading.
[11:50:24] <Barry Leiba> I think it's entirely nonsensical.
[11:50:25] <arvel> Barry: no - clear evidence of a verification done prior to x= should not be ignored simply because x= > current time now.
[11:50:26] <sftcd> doug: I wanted to ask that, wihch time value should the verifier use?
[11:50:45] <Barry Leiba> OK, it sounds like we're OK on that point, then.
[11:50:47] <Hector Santos> I'm having hard time following..
[11:51:00] <sftcd> for info: the x.509 algorithm in rfc3280 takes the checking tiime as an input
[11:51:06] <Hector Santos> Whats the current question/issue?
[11:51:21] <Barry Leiba> Let me recap... please hold off posting for a moment.
[11:51:32] <doug_trendmicro@jabber.org> The concept of received time would be when the message was received. Current time does not directly relate to the message.
[11:51:41] <Paul Hoffman> Doug: I don't think we can do that because we have no clear notion of "received" time, but we do know what time it is now.
[11:51:41] <Barry Leiba> 1. MAY vs. SHOULD/MUST. Resolved in favour of MAY.
[11:52:10] <doug_trendmicro@jabber.org> There should be a clear understanding when the message was received.
[11:52:15] <Barry Leiba> 2. Treat expired sig same as broken sig, agreed.
[11:52:21] <Barry Leiba> Doug, please stop.
[11:53:00] <Barry Leiba> 3. Verification is done at the time of verification, and expiration AFTER that has no effect... agreed.
[11:53:31] <Barry Leiba> 4. Current discussion: Doug brought up the issue of "current time" vs "received time".
[11:53:43] <Barry Leiba> Number 4 is where we are now.
[11:53:47] <Barry Leiba> OK... carry on.
[11:53:57] <sftcd> And hector used another time I think
[11:54:02] <Hector Santos> Ok, I proposed 4 as well. I agree with doug too.
[11:54:18] <Barry Leiba> (Doug, you may now un-stop. :-) )
[11:54:30] <sftcd> can the verifier reliable get that value?
[11:54:31] <Hector Santos> Transaction Reception Time which is the time the SMTP receiver will stamp the required Received: header.
[11:54:35] <doug_trendmicro@jabber.org> While the desire may be in most cases to use the UNIX time for judging expiration, there may cases where that basis is not correct.
[11:54:43] <doug_trendmicro@jabber.org> Take for example the MUA.
[11:55:08] <doug_trendmicro@jabber.org> When the message is received makes for a better measure whether the message should still be considered valid.
[11:55:32] <sftcd> if the received line isn't signed then I could fake stuff?
[11:55:45] <Barry Leiba> Doug, how long do you anticipate the delay between received time and verification time?
[11:55:46] <Jim Fenton> We are not trying to judge message validity, just signature validity.
[11:55:48] <Hector Santos> At the SMTP level, it will use the current time, but we need to help the post reception software too.
[11:55:54] <Barry Leiba> Jim: I agree.
[11:55:56] <Jim Fenton> Use Expires: for message validity.
[11:56:00] <Paul Hoffman> Jim: I agree.
[11:56:00] <Hector Santos> and that time comes from the Received header.
[11:56:16] <doug_trendmicro@jabber.org> It may be days before an MUA sees the same message as did the MTA.
[11:56:19] <Barry Leiba> Remember, too, that if the signer REALLY wants to kill the sig, it stops publishing the selector/key pair.
[11:56:34] <Barry Leiba> OK, Doug is looking at validation in the MUA.
[11:56:43] <Barry Leiba> The MUA issue seems to be the main sticker here.
[11:56:45] <Paul Hoffman> Doug/Hector: what do you see and the motivation for received vs. now?
[11:56:49] <Jim Fenton> Doug: That sounds like a good reason to do verification at the MTA whenever possible and not the MUA.
[11:57:07] <doug_trendmicro@jabber.org> I suspect the desire to get the MTA to stop accepting messages and not have the MUA invalidate already received messages that were not expired.
[11:57:24] <sftcd> huh?
[11:57:29] <Barry Leiba> I think we have always said that the aim is to do this in the MTA/MDA, but that we want to leave it open for doing in the MUA. Is that not correct?
[11:57:39] <Hector Santos> How many DKIM implementations will be burned into SMTP vs in post software filters like Spam Assasin?
[11:57:40] <Jim Fenton> Barry: Correct.
[11:57:42] <arvel> Jim: yes - the results of an MTA verification can be communicated to the MUA anyway in some future effort
[11:58:04] <doug_trendmicro@jabber.org> DKIM deployment must not depend upon both MTAs supporting DKIM and some type of results header (that is also not signed).
[11:58:07] <sftcd> And an MUA could pop up a dialog or whatevr (an MTA cannot)
[11:58:21] <Hector Santos> If we say DKIM is 100% SMTP level technology, then current time is fine. But it is the same time that would be used for the Received header which the post smtp software will use.
[11:58:28] <Barry Leiba> Does this still remain an issue with the switch to MAY, though?
[11:58:38] <doug_trendmicro@jabber.org> Separate
[11:58:41] <sftcd> can i ask again: is the received time reliably available anyway?
[11:58:54] <doug_trendmicro@jabber.org> Yes,
[11:58:58] <sftcd> there was a comment on the list that it wasn't
[11:59:11] <sftcd> but ok
[11:59:20] <sftcd> and does it matter that received may not have been signed?
[11:59:23] <Hector Santos> Yes Stephen
[11:59:39] <Barry Leiba> Stephen: If we assume MDA and MUA in the same administrative domain, I think the answer is yes.
[11:59:49] <Hector Santos> It is a received trace header for all SMTP receivers.
[11:59:59] <Barry Leiba> If the MUA can't assume, though, that the last Received line is believable, it's dicey.
[12:00:10] <doug_trendmicro@jabber.org> The signature still verifies, the decision is whether it was too old when first received.
[12:00:11] <Paul Hoffman> Wait, wait, wait. The current time will always be after the received time. So, if the current time is later than the x= value, so is the received time!
[12:00:21] <Barry Leiba> I don't think we need to design for nasty MDAs.
[12:00:30] <Hector Santos> I agree Barry. But how else do you past the "transaction reception time?"
[12:00:32] <sftcd> paul: don't think so
[12:00:46] <Barry Leiba> Paul, I think it's the other way 'round.
[12:00:54] <arvel> Why tie a DKIM verifier to something like SMTP forever though? Isn't there utility in keeping the verifier independent and letting it do it's own time? Just thinking (not sure)
[12:01:04] <Barry Leiba> Arvel has a good point.
[12:01:16] <sftcd> so the options are to compare x= against the last received line or else against now
[12:01:22] <sftcd> and the last received list is never signed
[12:01:24] <Barry Leiba> OTOH, using "received time" doesn't strictly tie us to SMTP.
[12:01:27] <sftcd> and therefore always replaceable
[12:01:30] <sftcd> hmmm
[12:01:32] <Barry Leiba> How about this:
[12:01:44] <Barry Leiba> "use received time if available, else use current time"
[12:01:45] <Barry Leiba> ?
[12:01:59] <sftcd> s/if available/if reliably available/
[12:02:03] <Barry Leiba> OK
[12:02:14] <Hector Santos> That is the text I have in my proposed x= text change in the mailing list
[12:02:19] <Barry Leiba> OK
[12:02:19] <Paul Hoffman> Why should the signer care which time is being used?
[12:02:26] <doug_trendmicro@jabber.org> Or you could say received time is the current time the message was received.
[12:02:32] <Hector Santos> The original one... A reference useful?
[12:02:32] <Barry Leiba> Verifier needs guidance.
[12:02:38] <Barry Leiba> I don't think the signer cares, no.
[12:02:52] <Jim Fenton> We really don't want to get into the business of parsing Received headers!
[12:03:00] <arvel> Ok on Barry's language but...
[12:03:03] <sftcd> that was what I heard on the list
[12:03:12] --- boxley has joined
[12:03:15] <Barry Leiba> Jim: I agree. Received time might be available in another way.
[12:03:17] <sftcd> I mean Jim's parsing remark
[12:03:27] <Paul Hoffman> Why does the "verifier need guidance"? It is a local policy.
[12:03:27] <arvel> nvm, it's ok :)
[12:03:52] <Barry Leiba> With sendmail, for instance, the milter could stash the received time somewhere for use later.
[12:04:08] <Barry Leiba> Paul: Hmmmm....
[12:04:19] <Barry Leiba> I think implementers want to "know" what to do.
[12:04:27] <Jim Fenton> What are the instances where received time is much different from current time? Are we referring to key retrieval problems?
[12:04:28] <Paul Hoffman> This feels like micromanaging the receiver on something that is a MAY.
[12:04:33] <arvel> it just seems counter-intuitive somehow to not have teh verifier use it's own determination for the time verification occurs but I'll go with the flow here.
[12:04:35] <Barry Leiba> I often see questions like that, which could/should be answered in the spec.
[12:04:44] <sftcd> jim: let's not get into key mgmt now
[12:04:45] <Barry Leiba> "What time do I use" might be one.
[12:05:02] <Barry Leiba> OTOH, Paul might be right that we should just leave it, and let the verifier decide.
[12:05:15] <Barry Leiba> Back to my question about whether the MAY change makes this not matter.
[12:05:20] <Jim Fenton> Stephen: Didn't mean to, I'm just trying to understand why current and received would be different by more than a few sec
[12:05:34] <sftcd> Barry: I think guidance is needed on this fwiw
[12:05:41] <Hector Santos> Current time will give post smtp software the wrong terminology. They will naturally figure out that it isn't the true time to use.
[12:05:43] <Barry Leiba> Jim: It's MTA vs MUA that makes this matter.
[12:06:01] <doug_trendmicro@jabber.org> Received time would be very different at the MUA for example.
[12:06:18] <Hector Santos> Doug: How so?
[12:06:30] <Barry Leiba> Does anyone OBJECT to saying "verifier SHOULD use received time if reliably available, else current time"?
[12:07:05] <sftcd> Not OBJECT but not sure at all
[12:07:10] <Paul Hoffman> Barry: minor objection that is adds another feature unneeded, but I can live with it.
[12:07:12] <Jim Fenton> I need to think some more about whether the received time is even the right thing to use
[12:07:15] <arvel> I'm not sure either
[12:07:30] <doug_trendmicro@jabber.org> If the message was place in the mailbox 4 days before being obtained by the MUA.
[12:07:32] <Hector Santos> OK with me Barry.
[12:07:33] <arvel> Would feel better with a MAY here also
[12:07:34] <Barry Leiba> OK, it sounds like this is something we need to go back to the list with.
[12:07:46] <Jim Fenton> I'd probably be OK with MAY.
[12:07:51] <sftcd> I can put [received|current] into strawman...
[12:07:54] <Barry Leiba> We have a change to the text queued, but we're not completely happy with it.
[12:07:55] <Paul Hoffman> Maybe this could be a informative note saying "you might choose X or Y depending on your needs"
[12:08:24] <Barry Leiba> I'm starting to think Paul's last comment is the best answer.
[12:08:35] <Jim Fenton> I think there's still an unresolved issue around the semantics of x= that is at the root of this issue.
[12:08:38] <doug_trendmicro@jabber.org> A circular definition such as received time is the current time the message was received.
[12:08:45] <Hector Santos> here is what I have for the informative text: <http://mipassoc.org/pipermail/ietf-dkim/2006q2/003134.html>
[12:08:49] <Barry Leiba> OK, so this one's settled as being unsettled. To the list with it.
[12:08:52] <sftcd> possible problem: using last recieved without checking all others are prior dates...
[12:09:10] <Barry Leiba> Jim: expand on semantics question, please.
[12:09:53] <Barry Leiba> Or should we call it over for time?
[12:09:57] <sftcd> jim slowwwly expands:-)
[12:10:04] <Barry Leiba> Are others OK with staying for a bit?
[12:10:07] <Hector Santos> MUA or time-shifted verification will always have some issue. The best we can work with is what the standard is, the SMTP required Received: header that all are required to stamp all messages with.
[12:10:09] <arvel> I am
[12:10:17] <doug_trendmicro@jabber.org> I am okay staying
[12:10:24] <Hector Santos> Ok here.
[12:10:38] <sftcd> agus mise (me too)
[12:10:44] --- tonyhansen has joined
[12:10:48] <Barry Leiba> Hi Tony
[12:10:53] <Jim Fenton> Barry: It has to do with whether the expiration is when the responsibility expires (so it must not verify OK after that time) or if it's when the signature isn't guaranteed to be verifyable (best before date).
[12:11:11] <tonyhansen> hi
[12:11:29] <sftcd> best-before could also reflect some higher layer semantic
[12:11:31] <boxley> we dont ant to tie a word like responsibilty and expiration together
[12:11:35] <Barry Leiba> Jim, I thought we agreed, earlier in the jabber, on the latter.
[12:11:54] <boxley> later please
[12:11:56] <Paul Hoffman> Jim: I think that's much bigger than x= and should be dealt with outside section 3.5.
[12:12:13] <Jim Fenton> Let's table it for now; I need to state it clearly and can't do that real-time on jabber.
[12:12:18] <Barry Leiba> OK
[12:12:19] <Hector Santos> ** RAISING HAND ***
[12:12:24] <Barry Leiba> Hector...
[12:12:57] <Hector Santos> How about Step 2 in Section 6.2 ... Might be a different subject if we are done with this time thing?
[12:13:38] <Barry Leiba> I don't have the spec in front of me. What are you asking?
[12:13:38] <sftcd> flicking pages in vi...
[12:14:04] <Hector Santos> This is the latest thread in the list. It is regarding...
[12:14:08] <sftcd> hector: you mean your putative step 0, don't get the key if x= is expired?
[12:14:28] <boxley> if x is expired why bother?
[12:14:37] <Hector Santos> That is anothe thing stephen... but it related. Because it helps with the 451 vs 551 response codes.
[12:14:59] <sftcd> ah, you better explain or send a URL then cause I dunno what's up
[12:14:59] <Paul Hoffman> Hector: I agree with Stephen. This is unrelated to getting the key. It is step 0 or 1.
[12:15:39] <Barry Leiba> Doug had an item... something about "5.2 7 days"?
[12:15:54] <doug_trendmicro@jabber.org> Yes.
[12:16:04] <Hector Santos> step 2 implies a 451 for deferring transactions when there is no key available. That would change to a 551 is the signarure expired.
[12:16:22] <Hector Santos> So....
[12:16:31] <doug_trendmicro@jabber.org> Can we change this to reference the period of the transit being protected than to recommend 7 days.
[12:16:41] * Barry Leiba has changed the subject to: DKIM meeting... agenda item 3, AOB
[12:16:50] <Hector Santos> My proposal is a MAY check expireation first, with allowance to check Key first to avoid the 451.
[12:16:50] <Paul Hoffman> Hector, if you check the expiration time and it is too late, you would never get to step 2.
[12:17:24] <Hector Santos> Paul agree. But its about the 451 response code. This forces senders to try again, again, again, again, again.
[12:17:41] <Barry Leiba> Hector, 451 is "can't contact key server". Key permanently unavailable should be 5xx.
[12:18:14] <sftcd> hector: I don't understand the effects of those codes enough so that's me out of this loop! :-)
[12:18:32] <Barry Leiba> Doug, I don't understand "being protected"
[12:18:34] <Paul Hoffman> Hector, if you are worried about that (I'm not), then we should put the expiration check before the key check.
[12:18:38] <Jim Fenton> Barry: That means that a signature that references an unavailable key gets treated much more negatively than an unsigned message
[12:18:46] <boxley> well since most bad actors ignore a 451 anyway
[12:18:51] <Hector Santos> 451 controls Senders to try again later. 551 controls sender to not send again.
[12:19:11] <Jim Fenton> Don't we just want to ignore the signature, not reject the message?
[12:19:14] <sftcd> Jim's point is a good one.
[12:19:14] <Barry Leiba> Jim, you're right. I shouldn't say 5xx.
[12:19:23] <Paul Hoffman> 451means try again later if you want.
[12:19:27] <Barry Leiba> But what I MEANT is NOT to send 451.
[12:19:28] <doug_trendmicro@jabber.org> The keys availability is to offer transit protection for some period of time. A sender may wish to ensure protection to the MUA for example.
[12:19:32] <boxley> and it will be a good heads up to the signer he has something misconfigured
[12:19:42] <Paul Hoffman> Jim is correct.
[12:19:49] <doug_trendmicro@jabber.org> The duration of this protection may affect the period of time the key is retained.
[12:20:11] <Barry Leiba> Doug (and others): I think we DO need to review the advice on key life in light of the obvious desire to do this in the MUA.
[12:20:11] <doug_trendmicro@jabber.org> 7 days in the case of the MUA transport being protected is too short.
[12:20:26] <Hector Santos> I do have a proposal to make everyone happy, I think. :-)
[12:20:34] <sftcd> shoot
[12:20:41] <Barry Leiba> Hector has it....
[12:21:07] <Hector Santos> Step 0: Verifiers MAY check the expiration.....
[12:21:39] <Hector Santos> or it may perform step 2 and use the combined information to determine 451 vs 551.
[12:21:52] <Hector Santos> More...
[12:22:01] <arvel> the spec isn't giving advice on SMTP result codes is it?
[12:22:05] <Hector Santos> NXDOMAIN + expiration = 551...
[12:22:11] <Barry Leiba> (451 vs 551 vs consider the sig as bad?)
[12:22:14] <Hector Santos> NXDOMAIN + no tag, no expiration = 451
[12:22:18] <Hector Santos> done.
[12:22:39] <Hector Santos> Arvel: It should.
[12:22:51] <sftcd> hector: In my ignorance that seems v. implementation specific. I'm probably wrong.
[12:22:53] <Barry Leiba> I think returning an SMTP permanent error falls into the "what to do after you've verified" area.
[12:22:58] <Jim Fenton> I'm still having trouble with rejecting the message based on something in the signature.
[12:23:08] <arvel> Barry: yes
[12:23:13] <Barry Leiba> So I think it's out of scope for the base spec.
[12:23:38] <Barry Leiba> Suggesting temporary error for temporary problems retrieving keys is fine, I think.
[12:23:52] <sftcd> So is the current text also badly placed?
[12:24:04] <Jim Fenton> Temp error: OK up to a point, but need to make sure that the message eventually does get through
[12:24:25] <Jim Fenton> assuming they are willing to retry, of course.
[12:24:37] <Barry Leiba> Does anyone object to Hector's step 0?
[12:24:41] <Jim Fenton> And it's only meaningful if the verifier is the MX host.
[12:24:46] <doug_trendmicro@jabber.org> No, the message may not.
[12:24:57] <Jim Fenton> Step 0 is fine, with MAY, since it's an optimization.
[12:25:12] <Barry Leiba> No objections.......
[12:25:14] <boxley> Step 0 is fine
[12:25:15] <arvel> I don't have a problem with Step 0 optimizing the process
[12:25:28] <Barry Leiba> OK, decision is to add Hector's step 0.
[12:25:29] <Paul Hoffman> I have a problem with combining step 0 and step 2.
[12:25:37] <doug_trendmicro@jabber.org> With or without step 0 is okay.
[12:25:43] <Barry Leiba> As to Doug's issue with 7 days...
[12:26:00] * boxley raises hand on doug's issue
[12:26:05] <Barry Leiba> I think, as I said earlier, we need to look at the timeouts in general, in light of the idea of doing this in MUAs.
[12:26:08] <arvel> raises hand also
[12:26:08] <sftcd> this is where I go off on 5 week holidays? :-)
[12:26:11] <Barry Leiba> boxley, go
[12:27:16] <boxley> In Implementation, a thoughtful designer would resign inbound messages at the message store with long expiration times so MUA's could verify,
[12:27:17] <Barry Leiba> (arvel, start typing, just don't press enter yet. :-) )
[12:27:50] <Barry Leiba> boxley: interesting idea, but what about non-compliant MTAs?
[12:27:53] <doug_trendmicro@jabber.org> The received time wording could handle the expiry term problem.
[12:28:15] <Barry Leiba> arvel, go.
[12:28:20] <arvel> this is a complex issue - on the one hand I agree with Doug and prefer to try and abstract the time period rather than a "7 days" specific statement but on the other hand I fear I don't understand all the implications of doing that so it makes me a little nervous.
[12:28:24] <boxley> and long periods between key changes mean the non compliamt will also still verify
[12:28:38] <sftcd> Bill: I would assume resigning would be part of murray's stuff?
[12:28:59] <boxley> well it does bring up multiple sigs
[12:29:08] <Paul Hoffman> This all seems like it is just advice for key admins. Shouldn't it be outside this document?
[12:29:13] <sftcd> ah yes correct - we need to fix that anyway
[12:29:23] <Barry Leiba> OK, we're really out of time here....
[12:29:27] <sftcd> sorry that last to Bill, agree with Paul
[12:29:35] <boxley> this is implementation stuff but doug wants to fuzzy the 7 day clause, I tend to agree
[12:29:45] <Hector Santos> One comment...
[12:29:46] <doug_trendmicro@jabber.org> I am only suggesting that the working indicate the duration of key retention include the period of transit protection desired by the sender.
[12:29:54] <Barry Leiba> I think we need to take the "7 days" issue to the list, and in general decide how to handle the potential longer time-lag of MUA validation.
[12:30:06] <sftcd> sound like a plan
[12:30:16] <sftcd> no more AOB?
[12:30:23] <Hector Santos> 7 days satisfy SMTP retry strategy. May not satisfy time for MUA pickup. So a 7+ X concept is needed.
[12:30:39] <Barry Leiba> I think the chairs, given Stephen's agreement, are going to officially close this at xx:30, now.
[12:30:41] <Hector Santos> agreed barry.
[12:30:48] <sftcd> But of course
[12:30:49] <Barry Leiba> But people may certainly stay on and talk about it.
[12:30:50] <doug_trendmicro@jabber.org> Should we try to provide should on d= != i=
[12:31:06] <Barry Leiba> It will be useful to have the discussion logged, so carry on (sans moderation) if you want.
[12:31:08] <Paul Hoffman> They ran out of free nuts at the bar, so we should leave.
[12:31:18] <Barry Leiba> Me, I'm going to lunch.
[12:31:19] <arvel> lol Paul
[12:31:26] <sftcd> One last formal thing; please give us feedback about the meeting. good/bad/indifferent all are needed.
[12:31:33] <Barry Leiba> (Lots of nuts there, but no bar.)
[12:31:44] <arvel> I'm off to see some of the sites in Chicago with the kids (brought them to the MS event)
[12:31:51] <Hector Santos> Oh, you didn't eat at the same time? Pollo Tropical here. :-)
[12:32:07] <hallam> What did the kids think of the MS event
[12:32:12] <sftcd> Dinner time here. So long folks!
[12:32:24] <arvel> They wonder what I'm doing talking to big shots like you Phil.
[12:32:31] * Barry Leiba has changed the subject to: DKIM meeting... officially ended -- free-form discussion time
[12:32:32] <Hector Santos> see ya stephen. this was fun! :-)
[12:32:41] <Jim Fenton> bye all!
[12:32:44] <sftcd> slan (bye)
[12:32:47] --- Jim Fenton has left
[12:32:52] --- Paul Hoffman has left
[12:32:57] <arvel> cya guys - try to have some fun today!
[12:33:01] <hallam> byee
[12:33:04] --- spirzada has left
[12:33:04] --- hallam has left
[12:33:12] <tonyhansen> I'm wondering where discussion of 451/551 should go
[12:33:22] --- arvel has left
[12:33:27] <tonyhansen> if not in base
[12:33:35] <Hector Santos> Hi Tony.. Hanging around abit?
[12:34:04] --- ogud has left
[12:34:05] <doug_trendmicro@jabber.org> We have been doing a fair amount of 451s.
[12:34:08] <tonyhansen> i'm i the airport, so have time :-)
[12:34:08] --- sftcd has left
[12:34:10] --- Peter Koch has left
[12:34:34] <doug_trendmicro@jabber.org> I don't think there will be a big issue provided it is base upon server failures.
[12:34:37] <Hector Santos> I thought Eric was going to write a section that described events and response codes. That was in the issues list if I recall.
[12:36:07] <tonyhansen> an "smtp effects" section?
[12:36:48] <doug_trendmicro@jabber.org> Don't forget that DKIM is not limited to just SMTP.
[12:36:49] <Hector Santos> If I recall, I propose a section summarize possible failures and recommended handling with response codes being part of the discussion.
[12:37:39] <doug_trendmicro@jabber.org> They have a few results codes, but they are not well defined.
[12:37:46] <Hector Santos> Doug, I think that is a given. How many MTA are going to burn DKIM into it vs most many sysops are going to add it via Seive or SpamAssasin?
[12:38:09] <tonyhansen> we'll have it burned in
[12:38:38] <doug_trendmicro@jabber.org> The real value of DKIM is ensuring the user is not spoofed.
[12:38:50] <doug_trendmicro@jabber.org> This happens with message annotation.
[12:39:05] <doug_trendmicro@jabber.org> That does not happen at the MTA in most cases.
[12:39:06] <Hector Santos> SPF's early quick adoption was because it was offered as both SMTP and POST-SMTP. Eventually we learned it worked better if at SMTP. I don't think it will be different with DKIM.
[12:39:21] <doug_trendmicro@jabber.org> Bad guys will be able to sign with DKIM>
[12:39:40] <Hector Santos> What are you using Tony?
[12:39:46] <boxley> bad guys can sign with anything
[12:39:58] <doug_trendmicro@jabber.org> Of course.
[12:40:05] <tonyhansen> dkim is not the end of the story -- have to add reputation lookup as well to get full answers
[12:40:19] <Hector Santos> Yes, absolutely.
[12:40:39] <doug_trendmicro@jabber.org> Annotation....
[12:40:42] <tonyhansen> we have home grown servers
[12:40:49] <boxley> most of this traffic wilol be handled on network edge devices not within the real mail handling cluster itself
[12:41:05] <Hector Santos> See my DSAP proposal I should submitted within a week - http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html
[12:41:36] <Hector Santos> This should stir the pot :-)
[12:41:40] <tonyhansen> our edge devices will most likely be running our smtp sw
[12:41:57] <boxley> as long as implementors can get a clear guideline on what is acceptable we will be okay, then on to authentication
[12:42:19] <doug_trendmicro@jabber.org> I have something as well:
[12:42:44] <Hector Santos> I had a interest talk with an AVS CTO recently about this....
[12:42:47] <doug_trendmicro@jabber.org> http://www.sonic.net/~dougotis/id/draft-otis-smtp-name-path-00.html
[12:43:18] <Hector Santos> He said that SMTP level methods is the wrong way to go for them.
[12:43:24] <doug_trendmicro@jabber.org> Who is sending the message will be as important as who is signing.
[12:43:26] <tonyhansen> another topic: doug, can you explain more your apparent distaste for using something like authentication-results to communicate the serve'sr verification results
[12:44:26] <doug_trendmicro@jabber.org> I don't want to wait for results headers to be deployed before DKIM can be used safely.
[12:44:36] <Hector Santos> boxley? Whats your name? If you don't mind.
[12:44:47] <doug_trendmicro@jabber.org> Just seeing a results header is not enough reason to consider it safee.
[12:45:36] <doug_trendmicro@jabber.org> If the results header is signed by the MDA, then that would be a different story.
[12:45:59] <doug_trendmicro@jabber.org> DKIM should offer handling advice for dealing with MDA signatures.
[12:46:13] <Hector Santos> Well, if I was in "control" of this stuff, I would make sure DKIM + Signature Authorization + Results were synchronized better.
[12:46:18] <doug_trendmicro@jabber.org> Such as how to recognize an MDA signature for example.
[12:47:14] <doug_trendmicro@jabber.org> There is no reason to wait for results headers. Get the critical sender to implement DKIM and give clients to the users. Done.
[12:47:32] <doug_trendmicro@jabber.org> That can happen very quickly.
[12:47:41] <Hector Santos> Doug: How?
[12:47:43] <tonyhansen> so your problem is not with A-R per se, but in it's current spec saying it's not signed somehow by the server?
[12:48:04] <doug_trendmicro@jabber.org> Expecting every ISP to change their MTAs and header handling will take much longer.
[12:48:07] <boxley> Sorry Hector, I was reading your draft, Bill Oxley Cox Communications
[12:48:39] <tonyhansen> how do the MUAs know if dkim verified, without forcing the MUA to do the verification itself?
[12:49:17] <tonyhansen> and you expect the MUAs to have support before the MTAs have support?
[12:49:24] <Hector Santos> Oh hi bill. :-)
[12:49:25] <doug_trendmicro@jabber.org> Two issues. Not having a method to know when the MDA is signing. Not having a signed results header as it not practical to known in the general case whether a results header is safe.
[12:49:42] <doug_trendmicro@jabber.org> The MUA does the verification.
[12:49:58] <doug_trendmicro@jabber.org> DKIM was designed to allow the MUA to do the verification.
[12:50:06] <boxley> will the mua do caching or hit dns everytime?
[12:50:17] <Hector Santos> Doug: I honestly think you can have your cake and eat it too if you allow DKIM+SSP to go thru :-)
[12:51:08] <doug_trendmicro@jabber.org> SSP is a problem. Bad actors will look like everyone else. SSP does not help.
[12:51:16] <tonyhansen> I'd rather not have my MUA doing verification and reputation lookups
[12:51:21] <doug_trendmicro@jabber.org> DNS has caching.
[12:51:38] <doug_trendmicro@jabber.org> The MUA can also selective authenticate.
[12:51:54] <doug_trendmicro@jabber.org> Sorry selectively authenticate.
[12:52:19] <Hector Santos> I think you are putting too much weight on MUA support. Unless you are writing one, why do you believe it will happen en mass?
[12:52:37] <boxley> I beleive he is writing one :-)
[12:52:41] <doug_trendmicro@jabber.org> Why do you think that it will not?
[12:53:06] <doug_trendmicro@jabber.org> The goal is quick deployment.
[12:53:19] <Hector Santos> I thought so. :-)
[12:53:59] <Hector Santos> Because we have 4-5 MUAs and trust me, it is better that we centralize the security in the back end.
[12:54:39] <Hector Santos> We will need to change the MUAs to make it understand results though.
[12:54:43] <doug_trendmicro@jabber.org> There is almost no way to stay ahead of the bad actors. Annotation is proactive and stays ahead of the bad actors.
[12:54:47] <boxley> doug, since edge mta's not mua's will be doing the signing, its easier to build a verification into the same piece of code
[12:55:22] <doug_trendmicro@jabber.org> The recipient is the critical element that needs to understand what is safe.
[12:55:22] <boxley> not to say that a mua verifier isnt a bad idea,
[12:55:40] <boxley> thanks guys, over m out
[12:55:49] --- boxley has left
[12:55:52] <doug_trendmicro@jabber.org> A DKIM signature passing SSP tests says nothing about what is safe.
[12:56:59] <tonyhansen> a dkim signature not passing SSP says loads about what is not safe
[12:57:13] <doug_trendmicro@jabber.org> In the end, restricting the use of email address will cause disruption and may make people shy away from DKIM.
[12:57:33] <doug_trendmicro@jabber.org> Not passing may say their ISP wants them to use their email-address.
[12:57:34] <Hector Santos> OK, in my view, unless the Federal Government mandates DKIM across all systems, DKIM will be of most value for those who provide a strong signature authorization policy. Why bother if it doens't have the help of verifiers?
[12:58:12] <doug_trendmicro@jabber.org> The verifier can be at the MUA
[12:58:43] <Hector Santos> Sure, but most likely will begin at the MDA or MFA (mail filtering agent).
[12:58:55] <doug_trendmicro@jabber.org> Don't expect the user to be able to recognize an email address. Both sides are about to be internationalized.
[12:59:45] <doug_trendmicro@jabber.org> A MFA is reactive and the phish attacks are fast paced.
[13:00:05] <doug_trendmicro@jabber.org> DKIM is about anti-spoofing.
[13:01:06] <Hector Santos> Sure, and in the end, I think most people agree that its best to stop the harm before it gets to the user. In fact, canada has a bill currently that wil enforce all ISPs to have AVS software.
[13:01:07] <doug_trendmicro@jabber.org> A reputable signer is more important than whether the email-address matches some sender policy.
[13:01:43] <doug_trendmicro@jabber.org> That is a bit different, although DKIM may help with that as well.
[13:01:47] <tonyhansen> AVS software?
[13:02:06] <Hector Santos> Doug, you have a lots of good points, but I think it lacks in practically. I don't mean that in a bad way. I dont' understand if you realize that view of yourself or not.
[13:02:08] <doug_trendmicro@jabber.org> We now have our fingers in that pie.
[13:03:08] <Hector Santos> Yes, the bill wil require that an ISP must install Anti-Spam/Virus software to protect users. Not having it can result in a fine or suilts.
[13:03:15] <doug_trendmicro@jabber.org> We do not agree on what is practical.
[13:03:55] <doug_trendmicro@jabber.org> You think that SSP is practical, but then it may require walking label trees looking for policies where few exist.
[13:04:00] <doug_trendmicro@jabber.org> That is not practical.
[13:04:05] <Hector Santos> Whats the fastest way for me to protect ALL my users? Writing backend software.
[13:04:29] <doug_trendmicro@jabber.org> Every element places a role.
[13:04:50] <doug_trendmicro@jabber.org> Where DKIM places a major role will be at preventing spoofs.
[13:05:08] <doug_trendmicro@jabber.org> This prevention can be proactive at the MUA and reactive at the MTA.
[13:05:34] <doug_trendmicro@jabber.org> Both are good, one is better.
[13:06:06] <Hector Santos> Do you have a product (or will have) that will support every MUA device known to man kind?
[13:06:21] <Hector Santos> What about mobiles?
[13:06:35] <doug_trendmicro@jabber.org> There will be a competitive market place that takes care of that concern.
[13:06:43] <doug_trendmicro@jabber.org> Mobiles as well.
[13:07:33] <Hector Santos> But then why would I want to put $$$ into redesiging our 4-5 MUAs devices when I can just do $$ with single-sourcing it via the backend?
[13:07:35] <tonyhansen> I need to go. keep dreaming big everyone!
[13:07:44] <Hector Santos> see ya tony:-)
[13:07:55] --- tonyhansen has left
[13:09:25] <Hector Santos> What about WebMail? Online MUAs? How about our console/ANSI/VT100 Telnet reading dumb terminal devices?
[13:10:31] <doug_trendmicro@jabber.org> Webmail is not a problem. VT100 terminals would require helper apps.
[13:11:51] <Hector Santos> Why is webmail not a problem? Are you going to install ActiveX components? What if the user doesn't allow it?
[13:13:20] <doug_trendmicro@jabber.org> There are two ways to skin that cat. Either at the browser or at the display app. Yes, there will need to be permission granted at the browser.
[13:14:50] <doug_trendmicro@jabber.org> The key point to remember is that when both halves of the email-address are internationalized, it will become very difficult for people to recognize one from the other.
[13:14:54] <Hector Santos> Sure. Doug, don't get me wrong. I'm sure you will make alot of money with an DKIM ready MUA, but you will need help from the backend also. But from a wide-scale standpoint, the obvious solution is at the backend first.
[13:16:27] <doug_trendmicro@jabber.org> There are many areas where DKIM helps. I expect there will be products Trend Micro develops at each of those points.
[13:17:38] <doug_trendmicro@jabber.org> Providing a quick free solution to combat much of the spoofing is needed.
[13:18:03] <doug_trendmicro@jabber.org> I don't see large profits, but rather a fair amount of effort.
[13:18:24] <Hector Santos> BTW, I find it interesting that I have not received 1 spam this week. :-) Who needs DKIM! :-)
[13:18:54] <doug_trendmicro@jabber.org> LOL. There is still spam out there.
[13:19:53] <Hector Santos> Yeah, but we we are blocking nearly all of it with no false positives. :-)
[13:20:27] <doug_trendmicro@jabber.org> Good show. There are still the major providers where this is problematic.
[13:22:13] <Hector Santos> Doug: Where are you located now?
[13:22:29] <Hector Santos> city
[13:22:36] <doug_trendmicro@jabber.org> San Jose, CA.
[13:23:03] <doug_trendmicro@jabber.org> It is 10:23 here.
[13:23:23] <Hector Santos> So it isn't lunch for you yet, well almost. Its freaking hot down here, near miami.
[13:24:07] <doug_trendmicro@jabber.org> I bet. There was a PBS special on global dimming which is saving us from it being worse.
[13:24:40] <Hector Santos> Global Dimming? Never heard of that. Blocking of heat?
[13:25:00] <doug_trendmicro@jabber.org> Blocking about 10-15% of the sunlight.
[13:25:09] <doug_trendmicro@jabber.org> Soot.
[13:25:48] <doug_trendmicro@jabber.org> The soot causes smaller droplets in the clouds and they act as mirrors.
[13:26:01] --- Barry Leiba has left: Replaced by new connection
[13:26:04] <Hector Santos> wow.
[13:26:27] <doug_trendmicro@jabber.org> I was shocked as well.
[13:26:47] <doug_trendmicro@jabber.org> I guess keep on smokin
[13:26:58] <doug_trendmicro@jabber.org> See you later.
[13:27:06] <Hector Santos> same here doug, take care..
[13:27:07] <Hector Santos> bye
[13:27:11] --- Hector Santos has left
[13:27:15] --- doug_trendmicro@jabber.org has left
[13:27:24] --- wildcat has joined
[13:27:36] --- wildcat has left
[14:08:08] --- wildcat has joined
[14:08:10] --- wildcat has left