[11:32:01] --- mrichardson has joined
[14:37:50] --- scicarus has joined
[14:38:14] --- scicarus has left
[15:59:10] --- Dave Cridland has joined
[16:00:47] --- eric has joined
[16:01:21] --- stephenfarr has joined
[16:05:16] --- jonathanclark has joined
[16:07:50] --- shima has joined
[16:09:22] --- doug_trendmicro@jabber.org has joined
[16:09:29] --- thomasm has joined
[16:10:29] --- robsiemb has joined
[16:12:20] --- Eliot.Lear has joined
[16:12:51] <Eliot.Lear> welcome to the second session of the dkim wg.
[16:12:54] --- fenton has joined
[16:12:55] <Eliot.Lear> i'll be scribing
[16:13:15] <Eliot.Lear> if you would like me to say a comment for you, please preface it with "MICROPHONE"
[16:13:49] --- gdweber has joined
[16:14:04] --- Eliot.Lear has left
[16:14:28] --- Eliot has joined
[16:14:34] <Eliot> this is eliot again
[16:14:39] <Eliot> we're now on issue 1231
[16:14:43] <Eliot> eric is at the mike
[16:15:34] --- Jim has joined
[16:15:35] --- robsiemb has left: Logged out
[16:15:36] <Eliot> dave crocker at mike
[16:15:57] --- robsiemb has joined
[16:16:29] --- Eliot has left: Logged out
[16:17:12] --- hartmans has joined
[16:17:17] --- Eliot has joined
[16:17:38] <Eliot> dave crocker: don't need to mention dns in base
[16:17:46] <Eliot> sam: is there a mandatory to implement?
[16:17:48] <hartmans> So, your specification needs to be complete enough that two implementations will interoperate. That means you need a mandatory to implement query mechanism.
[16:17:55] --- doug_trendmicro@jabber.org has left: Replaced by new connection
[16:17:58] <thomasm> i agree
[16:18:12] --- Jeff Yeh has joined
[16:18:12] <Eliot> barry: we need to hash this out a bit more on the list
[16:18:17] <thomasm> this sounds like it just gets you need several documents in parallel to rfc
[16:18:22] --- joncallas has joined
[16:18:45] <Eliot> reminder: if you want something spoken at the mike, preface it with MICROPHONE:
[16:18:49] --- robsiemb has left: Logged out
[16:18:53] --- Barry Leiba has joined
[16:18:57] <Eliot> Disposition of 1231: take it to the list
[16:18:58] --- ddayman has joined
[16:19:12] --- robsiemb has joined
[16:19:13] <Eliot> Next Issue: Clarify delegation to 3rd parties
[16:19:25] <Eliot> eric to propose wording
[16:19:35] <Eliot> jim fenton: 3rd party signatures or delegation of keys?
[16:19:39] <Eliot> stephen: the latter
[16:19:55] <Eliot> Next issue: base editorial
[16:20:05] <Eliot> 6.6 list of possible failures...
[16:20:16] --- tonyhansen has joined
[16:20:19] <Eliot> accept hector's issues
[16:20:30] <Eliot> Next Issue X= and clock Skew
[16:20:45] <Eliot> what if clocks skew between two machines and you have absolute times.
[16:20:53] <Eliot> politically correct answer is "use ntp"
[16:21:08] <Eliot> chris: use secure ntp?
[16:21:18] --- joncallas has left: Replaced by new connection
[16:21:22] <Eliot> paul hoffman: or get rid of x=
[16:21:34] --- ddayman is now known as Dennis Dayman
[16:21:46] --- Eliot has left
[16:21:49] --- pigdog@jabber.psg.com has joined
[16:21:58] <pigdog@jabber.psg.com> now up: SSP
[16:22:10] <pigdog@jabber.psg.com> Jim Fenton
[16:22:13] <thomasm> where are these slides?
[16:22:20] <pigdog@jabber.psg.com> hang on
[16:22:20] --- joncallas has joined
[16:22:50] <Barry Leiba> http://www3.ietf.org/proceedings/06mar/slides/dkim-2.pdf
[16:22:52] <pigdog@jabber.psg.com> slides are in the usual place for working group meetings. follow the link to agendas
[16:23:09] <pigdog@jabber.psg.com> SSP originally meant sender signing policy
[16:23:41] --- ekr has joined
[16:23:42] <pigdog@jabber.psg.com> maybe it should be originator signing practices?
[16:23:51] --- Lyndon Nerenberg has joined
[16:24:16] <pigdog@jabber.psg.com> suppose a verifier gets an unsigned message. what do you do with it?
[16:24:27] --- lisaDusseault@jabber.psg.com has joined
[16:24:33] <pigdog@jabber.psg.com> it would be helpful to know what the originating domain wants done
[16:25:03] <pigdog@jabber.psg.com> some messages are going to be suspicious
[16:25:11] <pigdog@jabber.psg.com> a mailing list might break a message, for instance
[16:25:27] <pigdog@jabber.psg.com> so you don't want to overreact when you get a message
[16:25:28] --- eric has left
[16:25:34] <pigdog@jabber.psg.com> so "suspicious" is intentionally vague
[16:25:46] --- kmurchison has joined
[16:26:00] <pigdog@jabber.psg.com> originator address is the address in the from: header field, and in this case specifically the first one
[16:26:21] --- eric has joined
[16:26:23] <pigdog@jabber.psg.com> you could use the sender, but it doesn't really make more sense to use the first address in the from header
[16:26:31] <pigdog@jabber.psg.com> why not use the purported responsible address?
[16:26:42] <pigdog@jabber.psg.com> we're interested in who the originator of the message is
[16:26:53] <pigdog@jabber.psg.com> as far as dkim is concerned, nobody is taking responsibility for the message
[16:26:59] <pigdog@jabber.psg.com> has nothing to do with ipr issues
[16:27:13] <pigdog@jabber.psg.com> barry: PRA makes sense on last hop
[16:27:20] <pigdog@jabber.psg.com> barry: for sender id (that is)
[16:27:28] <pigdog@jabber.psg.com> jim:
[16:27:34] --- utashiro has joined
[16:27:42] <pigdog@jabber.psg.com> people will need to sign messages who are other than the originating domain
[16:27:49] <pigdog@jabber.psg.com> an example: mailing list
[16:27:56] --- joncallas has left
[16:28:03] <pigdog@jabber.psg.com> applications may "legitimately" spoof messages
[16:28:11] <pigdog@jabber.psg.com> as in "send this news article to a friend"
[16:28:15] --- joncallas has joined
[16:28:27] --- arvel has joined
[16:28:31] <pigdog@jabber.psg.com> third party signatures allow external signers of messages to take responsibility for the message
[16:28:52] <pigdog@jabber.psg.com> arguably acceptance of a 3rd party is a security hole because anybody could sign a message for anybody else
[16:29:13] <pigdog@jabber.psg.com> clarification:
[16:29:31] <pigdog@jabber.psg.com> there are two third party cases, one where a key is delegated. that's not what we mean by 3rd party
[16:29:47] <thomasm> is the intent of this talk to be an overview? sorry I can't find the slides
[16:29:50] <pigdog@jabber.psg.com> in the other case, the 3rd party is siging with their own key
[16:29:51] --- robsiemb has left
[16:29:51] --- robsiemb has joined
[16:29:51] --- robsiemb has left
[16:29:54] <pigdog@jabber.psg.com> mike: yes
[16:30:19] <pigdog@jabber.psg.com> example.com SSP is located at
[16:30:23] --- robsiemb has joined
[16:30:25] <pigdog@jabber.psg.com> _policy._domainkey.example.com
[16:30:26] --- robsiemb has left
[16:30:44] <pigdog@jabber.psg.com> if you have a valid origination address, SSP is not needed
[16:30:47] --- robsiemb has joined
[16:30:50] <pigdog@jabber.psg.com> that's contentious
[16:31:12] --- john.levine has joined
[16:31:55] --- lisaDusseault@jabber.psg.com has left
[16:32:09] --- pigdog@jabber.psg.com has left: Logged out
[16:32:20] --- pigdog@jabber.psg.com has joined
[16:32:25] <pigdog@jabber.psg.com> eliot here again
[16:32:50] --- mcfadden has joined
[16:32:52] <pigdog@jabber.psg.com> now showing practices and the symbols associated with them
[16:33:06] <pigdog@jabber.psg.com> open issues
[16:33:09] --- joncallas has left
[16:33:18] <pigdog@jabber.psg.com> SPF format is terse. do you want to do that?
[16:33:35] --- joncallas has joined
[16:33:48] <pigdog@jabber.psg.com> perhaps there should be a few other practices, such as "i don't sign anything" or "i don't sign everytyhing, but don't accept a third party signature"
[16:34:01] <pigdog@jabber.psg.com> concerns about not consulting SSP if there is a valid OA
[16:34:17] <pigdog@jabber.psg.com> in some cases you might need to consult SSP to notice that there is a conflict
[16:34:29] <pigdog@jabber.psg.com> reporting address tag (r=)
[16:34:39] <Barry Leiba> Mike, does the URL I posted not work?
[16:34:53] <pigdog@jabber.psg.com> localpart only to keep reports going only to local domains
[16:34:58] <pigdog@jabber.psg.com> questions
[16:35:05] <pigdog@jabber.psg.com> tony hansen
[16:35:36] --- pigdog@jabber.psg.com has left: Logged out
[16:35:39] --- hallam has joined
[16:36:21] <thomasm> mic: we should agree what the concepts are before worrying about how to encode them, in particular it's not clear that the current set is correct and/or complete
[16:36:22] --- Eliot has joined
[16:36:59] --- ogud has joined
[16:37:10] --- pk has joined
[16:37:18] <Eliot> phillip hallam baker
[16:37:31] <Eliot> practices might bring a herd of lawyers down here
[16:38:10] --- joncallas has left
[16:38:16] <Eliot> types of anticipated attack are not the same for yahoo and bofa
[16:38:40] --- Eliot has left: Logged out
[16:38:57] --- Eliot has joined
[16:39:18] <Eliot> paul hoffman: is this a working group doc?
[16:39:26] --- joncallas has joined
[16:39:47] <Eliot> the intent is for this to be a wg draft
[16:39:58] <Eliot> goal was to focus on base first
[16:40:36] <Eliot> DKIM overview document
[16:40:38] <Eliot> Tony Hansen
[16:40:44] <Eliot> outline now on screen
[16:40:51] <Eliot> what it is and what it isn't
[16:41:33] <Eliot> intro explains why pgp and s/mime aren't used for this case
[16:41:58] <Eliot> some things might move from base to this doc
[16:41:58] --- resnick has joined
[16:42:09] <Eliot> mua considerations, delegation, 3rd parties
[16:42:24] <Eliot> is there anything that needs to be moved from the threats doc?
[16:42:37] <Eliot> was anything removed from earlier drafts that we might want to move into this?
[16:42:55] <Eliot> jim fenton: i only remember adding to it ... and adding to it...
[16:42:59] <Eliot> questions
[16:43:04] <Eliot> paul hoffman
[16:43:25] --- mcfadden has left: Logging off
[16:43:26] <Eliot> some people said let's rip anything non normative out of the base and place in here
[16:43:30] <thomasm> yuck
[16:43:31] <Eliot> barry: that's a possibility
[16:43:37] <Eliot> arvel:
[16:43:46] <Eliot> is this where the mailing list guidance will be?
[16:43:58] <Eliot> barry: good question. possibly a 2nd doc
[16:44:02] <thomasm> we need a bcp too
[16:44:03] <Eliot> arvel: keep guidance in one place
[16:44:08] <thomasm> not the same
[16:44:18] <Eliot> paul hoffman: in case mailing lists don't take advice, how should mua respond?
[16:44:29] <Eliot> barry; how does this tie into the bcp doc in the ASRG?
[16:44:43] <Eliot> john: seems reasonable for it to go there?
[16:44:59] --- joncallas has left: Replaced by new connection
[16:45:05] --- joncallas has joined
[16:45:11] <Eliot> there is there confusion in the room.
[16:45:20] <Eliot> barry: tony and john will work together to sort this
[16:45:36] <thomasm> mic: experience shows that multiple documents cause confusion for developers, and that the likelihood for incoherence is high
[16:46:14] <thomasm> ike
[16:46:19] <thomasm> yes
[16:46:48] --- doug_trendmicro@jabber.org has joined
[16:46:51] --- joncallas has left
[16:46:51] <Eliot> paul: agree with mike
[16:47:23] <Eliot> ikev1 was split, and ikev2 wasn't and [fewer mistakes]
[16:47:29] <Eliot> maybe not fair comparison
[16:47:44] <Eliot> jon callas: whichever way you do it you will decide the other way was better
[16:48:05] <Eliot> it makes it hard to publish into a new rfc pulls it out of last call
[16:48:16] <Eliot> doug otis, now up
[16:48:20] --- joncallas has joined
[16:48:48] <Eliot> base is at risk for a lot of attacks
[16:48:52] <Eliot> how do we defend dkim?
[16:49:12] <Eliot> when we look at how we assess dkim we'll ignore a lot of stuff.
[16:49:24] <Eliot> not all users are going to have secure systems or will be trustworthy
[16:49:48] <Eliot> message replay abuse, dos attack are problems with dkim
[16:50:10] <Eliot> we're limited to what we can see in the signed portion of the message
[16:50:28] <Eliot> evaluation is resource intensive, and ignores getting rid of undesired messages
[16:50:36] <Eliot> maybe use subdomains?
[16:50:40] <Eliot> don't do that
[16:50:43] --- joncallas has left: Replaced by new connection
[16:50:52] <Eliot> any message source can impact trust
[16:50:54] --- joncallas has joined
[16:51:20] <Eliot> key group tags can indicate unvetted sources,
[16:51:50] <Eliot> we'll end up annotating messages
[16:51:55] <Eliot> this overcomes lack of email policy
[16:52:22] <Eliot> source of alot of spam is zombies
[16:52:24] <Eliot> need a way to handle that
[16:52:28] <Eliot> key revocation doesn't work
[16:52:36] <Eliot> or is not practical
[16:52:42] <Eliot> an opaque id solves this problem
[16:52:48] <Eliot> allows for automated reporting
[16:52:54] <Eliot> and allows sender to do blacklisting
[16:53:20] <Eliot> how do we defend against replay?
[16:53:32] <Eliot> use EHLO verification
[16:54:00] <Eliot> example on slides
[16:54:09] --- ekr has left: Logged out
[16:54:31] <Eliot> open-ended / empty and closed ended
[16:55:05] <Eliot> you could associate third party signers by creating a list of them that you're using. it all goes into DNS as a PTR
[16:55:12] <Dave Cridland> There's some talk of eliding EHLO under some circumstances to reduce round-trips on ESMTP, particularly in mobile environments. Whether this comes to anything is another matter, but the discussion does exist. (Lemonade WG, threads involving Tony Finch).
[16:55:55] --- Eliot has left: Logged out
[16:56:29] --- Eliot has joined
[16:56:42] <Eliot> limited signature roles limit DoS attack
[16:56:56] <Eliot> jim fenton: is this related to key group?
[16:56:59] --- doug_trendmicro@jabber.org has left: Replaced by new connection
[16:57:31] <Eliot> jim: so guest would be a name for a key group?
[16:57:41] <Eliot> doug: by no means would this be a definitive list
[16:58:23] <Eliot> different types of bindings and roles...
[16:58:42] <Eliot> you would cache this and check to see if still valid when you're about to reject a message
[16:59:14] <Eliot> on opaque ids
[16:59:16] <Eliot> have u=
[16:59:27] <Eliot> and then <u>._dkim-revoke.<domain>
[17:01:12] <Eliot> these would be for whitelists and blacklists
[17:02:01] <Eliot> so this is a way of prioritizing resources
[17:02:12] <Eliot> questions
[17:02:31] --- Eliot has left: Logged out
[17:02:40] --- Eliot has joined
[17:02:50] --- shima has left: Replaced by new connection
[17:02:50] --- shima has joined
[17:03:48] <Eliot> jim fenton:
[17:04:09] <Eliot> concerned about the time to get information into dns
[17:04:19] --- resnick has left
[17:04:26] <Eliot> threat doc talks about two types of replay attacks.
[17:04:33] <Eliot> doug this is applicable to both
[17:04:39] <thomasm> mic: what evidence do we have that this is or ever will be a threat in the wild?
[17:05:08] <Eliot> (in queue)
[17:05:19] <Eliot> phillip hakam baker
[17:05:31] <Eliot> no compelling use case that would demand breaking layer abstractions
[17:05:57] <Eliot> there are some details that are worrying
[17:06:25] <Eliot> there are better ways to fix this
[17:07:29] <thomasm> that it *is* a threat in the wild
[17:07:57] <Eliot> mike, do i need to correct myself?
[17:08:02] <thomasm> no
[17:08:09] <Eliot> jim fenton
[17:08:37] <Eliot> to implement this requires a great deal of dns lookups, since the opaque identifiers are finer grain, they're not nearly as cachable
[17:08:51] <Eliot> the answer is to use the EHLO domain to decide whether to do the check.
[17:09:07] <Eliot> concerned about the number of mechanisms involved
[17:10:11] <Eliot> we're out of time. follow up on the list
[17:10:13] <Eliot> open mike
[17:11:04] <thomasm> i can't hear
[17:11:04] --- Eliot has left: Logged out
[17:11:16] <fenton> Tony Hansen speaking
[17:11:16] --- Eliot has joined
[17:11:25] <thomasm> speak into the mic
[17:11:26] <fenton> Introducing the message corpus
[17:11:53] <fenton> http://testing.dkim.org/messacecorpus or something like that
[17:12:03] <fenton> Tony had updated the corpus
[17:12:14] <fenton> (has updated)
[17:12:31] --- gdweber has left
[17:12:33] <fenton> Bunch of different test cases covered by the corpus
[17:12:37] --- hartmans has left
[17:12:37] --- joncallas has left
[17:13:01] --- joncallas has joined
[17:13:02] <fenton> Different message types and signature types
[17:13:22] <fenton> Multiple signatures too
[17:13:36] <fenton> Should there be negative tests as well?
[17:14:17] <fenton> Consensus that there should be negative tests, Tony solicits suggestions
[17:15:00] <fenton> Paul Hoffman: Are these actual messages or a tool for generating them?
[17:15:05] <fenton> Actual messages
[17:15:31] <fenton> Mark Delany doing some work in this area too
[17:15:36] <fenton> adjourn
[17:15:37] --- pk has left
[17:15:43] <fenton> (sorry for taking over Eliot)
[17:16:09] --- eric has left
[17:16:26] --- tonyhansen has left
[17:16:28] --- shima has left: Computer went to sleep
[17:16:34] --- Jim has left
[17:16:37] --- john.levine has left
[17:16:44] --- Jeff Yeh has left
[17:16:54] --- fenton has left
[17:16:56] --- utashiro has left
[17:17:10] --- Lyndon Nerenberg has left
[17:17:39] --- ogud has left
[17:18:11] --- hallam has left
[17:19:57] --- Eliot has left: Logged out
[17:19:58] --- robsiemb has left
[17:20:46] --- kmurchison has left
[17:22:37] --- thomasm has left: Logged out
[17:25:56] --- hallam has joined
[17:26:07] --- hallam has left
[17:26:21] --- hallam has joined
[17:29:00] --- stephenfarr has left
[17:33:09] --- Dennis Dayman has left
[17:36:12] --- hallam has left
[17:38:26] --- Barry Leiba has left
[17:38:59] --- joncallas has left
[17:39:43] --- pguenther has joined
[17:43:42] --- Dave Cridland has left
[17:50:50] --- arvel has left
[17:59:53] --- jonathanclark has left
[18:06:01] --- ogud has joined
[18:06:45] --- mrichardson has left
[18:09:16] --- pguenther has left
[18:13:22] --- hallam has joined
[18:17:30] --- stephenfarr has joined
[18:21:16] --- hallam has left
[18:33:38] --- stephenfarr has left
[19:13:32] --- ogud has left
[19:27:53] --- wildcat has joined
[19:28:53] --- wildcat has left
[21:09:03] --- arvel has joined
[22:24:37] --- arvel has left