ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] jabber logs into working group mailing list archives?

2009-04-01 10:59:48
Jim posted the WebEx chat.  I'm posting the jabber chat below (and I
also posted the WebEx chat to the jabber chat at the end of the
meeting, so it's all archived there as well.

Note that times in the WebEx chat are in PDT, while times in the
jabber chat are in EDT.  Subtract three hours from the EDT times to
get PDT, the local time of the meeting.

I agree that it's good to have this stuff here.  The chairs will make
sure it happens after each meeting.

Barry

---------------------------------------------------------------------------------------
[15:48:32] dcrocker joins the room
[15:50:09] fenton joins the room
[15:50:27] fenton has set the subject to: DKIM WG at IETF 74
[15:57:55] semery joins the room
[15:58:47] sm joins the room
[15:59:09] prussell(_at_)nd,edu joins the room
[15:59:15] mrex joins the room
[16:00:24] eliot.lear joins the room
[16:00:35] <eliot.lear> greetings
[16:00:53] Melinda joins the room
[16:01:41] <fenton> Chairs are looking for scribes
[16:01:48] bruce joins the room
[16:01:55] fujiwara joins the room
[16:01:57] franck(_dot_)martin(_at_)jabber(_dot_)org joins the room
[16:02:04] <eliot.lear> i'm not getting any streaming content yet
[16:02:16] <sm> Did you try webex?
[16:02:22] <eliot.lear> doh!
[16:02:30] David Cooper joins the room
[16:02:31] <bruce> still casting around for various roles.
[16:02:39] <mrex> I'ma als eagerly waiting for the audio stream
[16:02:52] <fenton> We're on WebEx as well, yes
[16:03:14] <eliot.lear>
https://workgreen.webex.com/workgreen/j.php?ED=108103882&UID=1056672507&PW=73ef359be60800070b&RT=MiM0
[https://workgreen.webex.com/workgreen/j.php?ED=108103882&UID=1056672507&PW=73ef359be60800070b&RT=MiM0]
[16:03:26] <eliot.lear> password "dkim"
[16:03:26] jtrentadams joins the room
[16:03:40] <fenton> is the IETF audio stream down?
[16:03:51] <fenton> we aren't saying much right now, though...
[16:03:52] <sm> Let me see
[16:04:15] rlbob joins the room
[16:04:25] <mrex> I can hear audio now
[16:04:26] pee000 joins the room
[16:04:40] dan(_dot_)hoopyfrood(_at_)gmail(_dot_)com joins the room
[16:04:47] <mrex> the new audio streaming seems to have a hang-over
every morning
[16:05:04] <rlbob> much like some WG co-chairs
[16:05:39] John Schnizlein joins the room
[16:05:47] <sm> Audio stream is working
[16:05:51] markkao joins the room
[16:06:07] sftcd joins the room
[16:07:39] <fenton> sm: thanks
[16:08:25] <mrex> I've been doing jabbber&Audio-streams for several
years -- that's been working fine (in the IETF security area, at
least) -- many thanks to the local participants
[16:10:02] jcossio joins the room
[16:10:03] <bruce> just went through draft-ietf-dkim-overview, now
draft-ietf-dkim-deployment
[16:11:14] jdfalk joins the room
[16:11:21] joncallas joins the room
[16:11:30] <bruce> slide dkim d, d&o
[16:12:01] Ned Freed joins the room
[16:12:05] ESiegel joins the room
[16:12:51] <mrex> is the presentation up on the IETF datatracker yet?
[16:13:04] <sftcd> no yet, shortly
[16:14:01] <sftcd> there are no slides for this part
[16:14:54] Doug Otis joins the room
[16:15:04] Doug Otis leaves the room
[16:15:30] Doug Otis joins the room
[16:16:13] Doug Otis leaves the room
[16:21:06] john.levine joins the room
[16:27:58] <sftcd> jim fenton is making the point that there can be
other outputs as well as an identifier
[16:28:38] <sftcd> dave crocker is making the point that all the
documents we've produced (incl. 4871) do say that the output is an
identifier
[16:33:31] Doug Otis joins the room
[16:34:13] klaas(_at_)im(_dot_)wierenga(_dot_)net joins the room
[16:36:03] prussell(_at_)nd,edu leaves the room
[16:36:22] prussell(_at_)nd,edu joins the room
[16:36:47] <jdfalk> the hubbub about i= vs. d= wasn't caused by ADSP,
but rather by concerns about which identifier will be used in
reputation
[16:36:53] <john.levine> right
[16:37:00] <john.levine> can someone pass that along to the room?
[16:37:06] <sftcd> will do
[16:37:11] <jdfalk> thanks
[16:38:50] tonyhansen joins the room
[16:38:58] <eliot.lear> mic:
[16:40:04] pk joins the room
[16:40:15] <sm> Question: where is the signing domain opaque then?
[16:40:24] <sm> s/where/why/
[16:40:34] <eliot.lear> people keep claiming interoperability
concerns. The problem is that we are fighting bad guys and attempting
not to be gamed. Attempt to limit flexibility and either we will get
gamed, or we will be ignored. So this is a +1 to what mike thomas
said.
[16:41:06] <sftcd> eliot: was all that for the mic?
[16:41:25] <john.levine> The more options you offer, the more
opportunities bad guys have to game you.
[16:41:30] <john.levine> (for mic if Eliot's was)
[16:41:52] <eliot.lear> yes, please
[16:41:58] <sftcd> will do
[16:42:03] <eliot.lear> john- i think that's unproven.
[16:42:13] <eliot.lear> but perhaps you can clue me in?
[16:42:29] <john.levine> the most obvious example is l= which
introduces new attacks
[16:42:58] <john.levine> this is what I meant about blacklist vs.
whitelist thinking
[16:42:58] <franck(_dot_)martin(_at_)jabber(_dot_)org> it is likely to be an 
arm race
[16:43:07] <eliot.lear> franck: right
[16:43:12] <ESiegel> the signing domain is opaque in the sense that we
can't add semantic value to the components. I.e., I can call my
signing domain pristine.mydomain.com and then send all spam email...
treating the domain component "pristine" as opaque means that we won't
second-guess the categorization, that we'll just rely on the actual
traffic to establish its reputation
[16:43:13] <eliot.lear> i would agree with john to this extent:
[16:43:25] <eliot.lear> simpler is generally better
[16:43:37] klaas(_at_)im(_dot_)wierenga(_dot_)net leaves the room
[16:43:37] <eliot.lear> but we need to stop short of telling
implementations how to evaluate veracity
[16:43:51] hsantos joins the room
[16:44:03] <sm> Ellen, then who is claiming responsibility?  BTW, I
understand your point
[16:45:10] <ESiegel> the d= value is claiming responsibility. the
point about opacity just means that we need to use actual experience
rather than our semantic interpretaiton of the domain name components
to determine what reputation to assign to that mail stream / signing
entity
[16:45:30] <franck(_dot_)martin(_at_)jabber(_dot_)org> May be the specs needs 
to be
left simple and open till experience is gained by large deployment,
and then allow to review and tighten
[16:45:33] <Doug Otis> IMO, reputation will require d= first and i=
second if it exists.  It might be replaced by r= for that matter.
There does not seem to be a good reason to change RFC 4871 in that
respect.  A BCP seems like a better place for that type of
information.
[16:45:58] <hsantos> I agree with otis.
[16:46:22] lynch joins the room
[16:46:54] Michael Adkins joins the room
[16:48:17] <franck(_dot_)martin(_at_)jabber(_dot_)org> large ESP doing 
reputation, will
not tell their formula but can be guided by BCP, but open projects
like spamassassin need guidance (via BCP)
[16:48:48] <hsantos> Interesting point Franck.
[16:48:56] <eliot.lear> but ellen, that's not what "opaque" means
[16:49:00] Doug Otis leaves the room
[16:49:21] <jdfalk> seems like the people most scared of choosing the
wrong identifier are on the sending/signing side, not the verification
& assessment side
[16:49:39] <eliot.lear> jd, that's a very good point
[16:49:44] <eliot.lear> someone should say that at the mic
[16:49:51] <jdfalk> yes please
[16:50:31] <franck(_dot_)martin(_at_)jabber(_dot_)org> large ESP are already 
doing a
good reputation verification, it is for home companies running their
little MTA, but DKIM needs large ESP to gain implementation
[16:50:31] <Michael Adkins> have they ever tried querying an ip dnsbl
with the from address?
[16:50:45] <dcrocker> jd, 'scared of choosing the wrong identifier'?
pls clarify
[16:51:14] <sm> Michael, DKIM does not say anything about the From: address.
[16:51:48] <eliot.lear> sm, i thought you had to sign it
[16:51:54] <jdfalk> they want to know which identifier their
reputation will be associated with
[16:51:58] <sm> Yes, you sign it (MUST)
[16:51:59] <sftcd> was there something for me to say at the mic?
[16:52:08] <eliot.lear> and jd, that's gaming.
[16:52:12] <jdfalk> nah, the conversation has moved past it
[16:52:29] <sftcd> jdfalk: ok
[16:52:34] <john.levine> You have to sign the From: line, but that
doesn't make any promises beyond saying that the From: line in the
verified message is the same one that was signed, not that it's
"real".
[16:52:51] <Michael Adkins> that's not what I was saying :)
[16:53:14] <jdfalk> eliot: sometimes it's gaming, and sometimes
they're sending for multiple clients and want to ensure that each
client's reputation is distinct. whether assessors will let them get
away with that is a separate question....
[16:53:50] <eliot.lear> john, Section 5.4 first sentence (rfc4871)
[16:54:22] <franck(_dot_)martin(_at_)jabber(_dot_)org> jd: agreed
[16:54:35] <eliot.lear> from the receiver's perspective, jd, that's
secret sauce (IMHO).
[16:54:54] <john.levine> 5.4 says you have to sign the From: line --
but it doesn't say that you are only supposed to sign From: lines that
you you know to be the true name of the sender
[16:55:07] <eliot.lear> i agree
[16:55:12] <eliot.lear> (john)
[16:55:19] <jdfalk> couldn't tell whether doug is in favor of the
errata, or against it -- though it sounded like his points were in
favor of it
[16:55:36] <ESiegel> JD: this point of single output did not originate
with any sender. The point is to remove ambiguity, not to game the
system. It's hard, or at least harder, to game the system if there's
no ambiguity and if reputation is determined by the behavior of the
mail stream.
[16:55:38] <eliot.lear> i'm not sure, jd, that's the discussion
[16:56:48] <eliot.lear> to dave, jim's point is when you differentiate
you actually create interoperablity risks
[16:56:52] <jdfalk> well...assessors will assess whatever data we can
derive (or surmise)
[16:57:08] Doug Otis joins the room
[16:57:26] <sm> Doug, are you in favor of the errata?
[16:57:29] <jdfalk> +1 to dave's point about separating the various
sorts of crap
[16:57:52] <eliot.lear> it's not a collaborative exchange!!!!
[16:58:17] <eliot.lear> the receiver has to consider the sender
hostile until proven otherwise
[16:58:31] <eliot.lear> and the receiver gets to decide what proof it
wants to use
[16:58:36] <john.levine> +1 to Dave's point, it's an identifier
[16:58:45] <Michael Adkins> and once proven otherwise, how would you
describe the exchange?
[16:59:01] <eliot.lear> it's not EVEN an exchange
[16:59:29] <Michael Adkins> how would you characterize the process then?
[16:59:38] <eliot.lear> an evaulation, mike
[16:59:44] <Doug Otis> sm:  The use of the terms opaque is troubling
and does not belong in the errata.
[16:59:50] <eliot.lear> although i would spell it correctly ;-)
[17:01:33] <Michael Adkins> I think Dave is referring to the use case
of a signer collaborating with an assessor
[17:01:41] <Michael Adkins> as being the 'main' use case
[17:01:50] <Michael Adkins> which is why he likes to characterize it
in those terms
[17:01:54] <eliot.lear> but do you believe that?
[17:01:55] <Doug Otis> The d= value is more than just an identifier,
it also potentially relates to domains within signed headers.
[17:02:51] <eliot.lear> who is this?
[17:02:58] <eliot.lear> murray?
[17:03:05] <sm> No
[17:03:08] <eliot.lear> mike?
[17:03:09] <sm> Mike
[17:03:13] <eliot.lear> ok
[17:03:20] <Michael Adkins> lol
[17:03:34] <Michael Adkins> no one's using it yet....
[17:03:52] <Michael Adkins> because they can't figure out how to
[17:03:56] <john.levine> MIC: please say who you are, we don't all
recognize your voice
[17:04:22] <Michael Adkins> elliot, I think the main use case will be
positive reputation
[17:04:40] <Michael Adkins> 'main' as defined as impacting the largest
amount of mail
[17:04:51] <dcrocker> jd, it might be worth hashing a bit on your
sender (vs. receiver) distinction.  There are all sorts of different
people and different perspectives participating in each view.  However
I think that the basis for the rough consensus was developed primarily
among people who are deeply involved in fighting spam and the bulk of
those against was not.
[17:05:00] <Michael Adkins> senders will try to collaborate with us
whether we want or need them to or not :)
[17:05:00] sm leaves the room
[17:05:32] sm joins the room
[17:05:53] <Michael Adkins> so, I mostly agree with Dave's assessment
of the main use, but I disagree on the specifics of the use model
[17:05:57] <jdfalk> who is speaking?
[17:06:06] <dcrocker> guys, we *already* have senders participating in
the errata.  pls get the f off sender slamming.  they get all of that
they need at maawg...
[17:06:07] <eliot.lear> that's still mike, i think
[17:06:16] <dcrocker> yeah, michael.
[17:06:28] <franck(_dot_)martin(_at_)jabber(_dot_)org> spam from bad people is 
zombie
based, if dkim can stop that, this would be great
[17:06:32] <sftcd> barry offered the following possible statement for
the erratum draft as a way to resolve the issue: The verifier MUST
supply the signing domain to the assessor.  The assessor MAY use other
information, including information included in the DKIM signature
header field, in making its assessment.
[17:06:33] <hsantos> michael who?
[17:06:41] <franck(_dot_)martin(_at_)jabber(_dot_)org> other will want to 
behave with
the recipient
[17:06:41] <sftcd> mike thomas
[17:06:45] <eliot.lear> dave, you're missing my point- it's not the
nice senders i'm worried about
[17:06:50] <eliot.lear> and those are the ones who show up at MAAWG
[17:07:05] sm-msk joins the room
[17:07:11] <sm-msk> aha
[17:07:49] <jdfalk> scrolling back a bit...I'm not saying the folks at
the sender/signer end of the transaction should be ignored or
discounted, but rather clarifying that the loudest demands for d=/i=
clarification aren't coming from assessors
[17:07:58] <jdfalk> stupid smilies
[17:08:02] <jdfalk> d= / i=
[17:08:23] <eliot.lear> right.
[17:08:46] eronenp joins the room
[17:09:26] <joncallas> Make it be a semicolon if you want a single
sentence. (I'm smiling as I say it, but I'm serious.)
[17:09:53] <Michael Adkins> Doug's only taking about things that
matter if there is an ADSP record for the domain
[17:12:55] <sm> Dave says "permitting a person, role or organization
that owns the signing domain to claim responsibility" in the errata
"

[17:13:33] <hsantos> Am I the only one that have a problem with the
term "Responsibility?"
[17:14:26] <dcrocker> jd, my point is stronger than yours.  the
loudest demands (esp. for vagueness) are coming from folks not living
in the world with the problem DKIM is trying to help solve.
[17:14:29] <sm-msk> i don't have a problem with it
[17:14:35] <sm-msk> with that word
[17:14:44] <jdfalk> dave: good point.
[17:15:16] John Schnizlein leaves the room
[17:15:20] <sm> Hector, responsible for relaying the message.
[17:15:54] resnick joins the room
[17:16:11] <hsantos> hmm,  the entity who signs is claiming responsibilty.  No?
[17:16:41] <sm> responsible for signing it:)
[17:17:49] <jdfalk> this is such a wide-ranging conversation...what
happened to the errata?
[17:18:08] <eliot.lear> who is this?
[17:18:11] <sm-msk> tony hansen
[17:18:14] <sftcd> tony hansen
[17:18:15] <eliot.lear> thanks
[17:20:25] <Doug Otis> The i= value may match with an email-address
within a signed header, or may not match in which case it should not
be considered real.  This is not accurately described as always being
opaque.
[17:20:38] <jdfalk> right, verifiers simply can't assume that i= is a
user -- or anything else -- unless there's an out-of-band
communication of some sort
[17:20:52] <sftcd> I'm sure that "not real" is not the term we want;-)
[17:21:32] <sm-msk> but 4871 doesn't say anything about interpreting
i=, so i'm not sure that's an important point right now
[17:22:59] <jdfalk> it's verified that it was signed by that domain.
that's all. the trust assessment is separate.
[17:23:29] <sm-msk> yeah, it's unchanged from signing to verifying
[17:23:36] <sm-msk> that's all you can say
[17:25:03] <hsantos> But there is a BASE ACCESSOR - the 1st domain
signing domain.
[17:25:34] <sm-msk> huh?
[17:26:05] <hsantos> Is this dave talking?
[17:26:08] <Michael Adkins> yeah
[17:26:10] <john.levine> yes
[17:28:04] dan(_dot_)hoopyfrood(_at_)gmail(_dot_)com leaves the room
[17:28:09] resnick leaves the room
[17:28:37] <sftcd> ellen siegel speaking
[17:28:48] resnick joins the room
[17:30:04] <hsantos> I agree with Ellen's point.
[17:30:08] <Michael Adkins> how many assessors are involved in this
conversation?
[17:30:34] <hsantos> I think we have a base accessor which is the
original domain that needs to be taking into account. Doesn't the
original author domain have control anymore?
---------------------------------------------------------------------------------------
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>