[03:14:56] --- mrichardson has left
[03:49:12] --- dcrocker has joined
[04:17:22] --- dcrocker has left
[09:57:39] --- paulwouters@jabber.org has joined
[10:24:58] --- dcrocker has joined
[10:28:26] --- dcrocker has left
[10:31:26] --- dcrocker has joined
[10:49:51] --- paulwouters@jabber.org has left
[10:55:16] --- paulwouters@jabber.org has joined
[11:01:36] <paulwouters@jabber.org> no audio feed yet?
[11:03:37] --- john.levine has joined
[11:04:20] --- john.levine has left
[11:31:33] --- dcrocker has left
[11:33:45] --- fenton has joined
[11:34:32] <fenton> No projector in the room either, so I assume the A/V people have some work to do yet.
[11:34:49] <eric> i'm hearing a lot of background noise on the audio.
[11:34:54] <eric> low rumbling.
[11:35:07] <eric> loud enough that it will probably be hard to hear.
[11:35:19] <eric> yes
[11:35:36] <eric> but it is still not loud compared to the noise.
[11:35:54] --- Stephen Farrell has joined
[11:39:16] <Stephen Farrell> There's a guy working on the audio boxes but not promising too much
[11:40:04] <eric> i'll keep my fingers crossed. i'm going to try another channel to see if it's the entire feed.
[11:43:39] --- doug.otis@gmail.com has joined
[11:43:41] <eric> all the even numbered channels are clean; all the odd numbered seem to have at least a little bit of noise.
[11:43:55] --- arvelh has joined
[11:43:56] <eric> five is pretty clean; 1, 3, and 7 are nasty.
[11:44:45] <eric> ah, i see a note at the bottom of the videolab page: "2006 Nov 11 Audio on Channel 1 and 7 are noisy. We are not able to resolve this problem."
[11:44:54] <eric> interesting that it's dated the 11th, four days from now....
[11:46:54] --- Barry Leiba has joined
[11:47:53] * Stephen Farrell has set the topic to: DKIM Meeting starts in 10
[11:48:08] --- tonyhansen has joined
[11:52:27] --- ddayman has joined
[11:55:27] --- psavola has joined
[11:55:34] --- thomasm has joined
[11:56:02] * Stephen Farrell has set the topic to: DKIM Meeting starts in 5
[11:57:40] --- JLCjohn has joined
[11:59:34] --- pigdog has joined
[12:00:25] <arvelh> hi everyone
[12:00:26] * Stephen Farrell has set the topic to: DKIM Meeting
[12:01:03] <pigdog> good morning, eliot here. i'll be your jabber scribe. arvel will announce comments to the mike. Say "MIKE:" when you want something said at the Mike
[12:01:23] <pigdog> Barry has just brought the meeting to order
[12:01:42] <ddayman> FyI: it's a little hard to hear him
[12:01:58] --- pguenther has joined
[12:01:58] <pigdog> we are aware that audio quality is not the best.
[12:02:01] --- wouter has joined
[12:02:01] --- ms has joined
[12:02:08] <pigdog> agenda bashing
[12:02:12] --- ajsaf@jabber.org has joined
[12:02:14] --- alexeymelnikov has joined
[12:02:25] --- glozano has joined
[12:02:27] <pigdog> barry will present for michael thomas
[12:02:35] <pigdog> then four proposals for SSP protocol
[12:02:35] --- kmurchison has joined
[12:02:44] --- Simon Josefsson has joined
[12:03:02] <pigdog> open mike after proposals
[12:03:13] <pigdog> all slides are available on the meeting materials page
[12:03:16] <pigdog> comments?
[12:03:25] <pigdog> last call ends today on base
[12:04:23] <pigdog> ssp requirements draft is almost ready for WGLC
[12:04:30] <pigdog> small number of issues
[12:04:39] <pigdog> overview is progressing
[12:04:48] --- rstory has joined
[12:05:16] --- dcrocker has joined
[12:05:25] --- resnick has joined
[12:05:49] <pigdog> meeting materials: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
[12:07:03] <pigdog> goal of the meeting is to get consensus of requirements and start to head toward consensus on proposals
[12:07:58] <pigdog> barry
[12:08:01] <pigdog> milestones
[12:08:23] <pigdog> policy specification is late and should be. we need to change the milestones to something more real
[12:08:46] --- kurosaki has joined
[12:09:02] <pigdog> barry is now doing michael's slides
[12:09:44] <pigdog> mike did the requirements draft to help people figure out what ssp should be
[12:10:02] <pigdog> summary of major changes is now on the screen
[12:10:10] <pigdog> remaining requirements
[12:10:18] <pigdog> 6.3.1 "I send no mail"
[12:10:29] <pigdog> people are already doing it, but it really doesn't have anything to do with dkim
[12:10:52] <pigdog> 6.3.8 local part practices
[12:11:12] <pigdog> this is about breaking out policies on localpart versus subdomain
[12:11:23] <pigdog> its function could be done using subdomains
[12:11:42] <pigdog> pros: allows more incremental deployment
[12:11:47] <thomasm> it would be nice to get a read on whether these should be nuked or stay from the room...
[12:11:56] <pigdog> 6.3.12 crypto bid down
[12:12:34] <pigdog> jim fenton
[12:13:00] <pigdog> localpart practices have the potential to add alot of overhead to due to extra lookups
[12:13:11] --- resnick has left: Replaced by new connection
[12:13:15] <pigdog> doug otis:
[12:13:31] <pigdog> can be done economically without requiring additional lookups
[12:13:43] <pigdog> if you start using a lot of subdomains it gets easier to spoof
[12:13:50] <pigdog> dave crocker:
[12:14:12] <pigdog> no protocol like ssp has been promulgated on the internet before. doesn't mean we shouldn't do it, but we should be careful.
[12:14:42] <pigdog> the criteria we should use is whether the mechanism is absolutely essential either for initial functionality or for extensibility
[12:14:54] <pigdog> phb:
[12:15:42] <pigdog> we have never managed to successfully transition to a state of pervasive security. it is almost impossible to change a protocol once it's deployed, because there is no policy layer.
[12:16:00] <pigdog> you can have a policy layer that is simple but powerful
[12:16:04] <pigdog> paul hoffman:
[12:16:15] --- ms has left
[12:16:41] <pigdog> we have tried policy before and gotten some protocols done. they took forever to get done, and were thinly implemented. think ipsec policy (ipsp)
[12:16:54] <pigdog> just because one can do something doesn't mean one should.
[12:17:00] <pigdog> they had laudable goals
[12:17:10] <pigdog> but is this enough?
[12:17:44] <pigdog> dave crocker:
[12:18:03] <pigdog> good stuff to try, but again approach in the most cautious way we can.
[12:18:26] <pigdog> there is pretty strong interest in this
[12:19:01] <pigdog> simple mechanism with simple extension mechanism
[12:19:06] <pigdog> think ESMTP
[12:19:19] <pigdog> so suggest that we split "I send no mail" off to another document.
[12:19:23] <pigdog> stephen:
[12:19:32] <pigdog> agrees on the winnowing approach
[12:19:37] <pigdog> barry:
[12:20:20] <pigdog> we will return to this at open mike time
[12:20:27] <pigdog> open issues from the tracker
[12:20:47] <pigdog> 1383: This document's ultimate fate?
[12:21:09] <thomasm> dave crocker
[12:21:11] <thomasm> yes
[12:21:26] --- Jim Galvin has joined
[12:21:28] --- patrickn has joined
[12:21:32] <pigdog> mike has folded in clarifications from dave and the group
[12:21:55] <pigdog> dave will take an action to confirm these actions are closed - this week.
[12:22:12] <pigdog> this includes 1356, 1357, 1362 and 1363
[12:22:22] <pigdog> 1382. new rr type
[12:22:46] <pigdog> other issues?
[12:22:52] <pigdog> other requirements?
[12:22:58] <pigdog> overall "closeness"?
[12:23:02] <pigdog> simpler is better...
[12:23:06] <pigdog> are we ready to go with it?
[12:23:15] <pigdog> doug otis:
[12:23:17] --- ms has joined
[12:23:48] <pigdog> we want to see dkim provide a benefit. we should be careful about how much management is required
[12:24:09] <pigdog> "simple" doesn't mean leaving off features...
[12:24:13] <pigdog> jim fenton:
[12:25:46] <pigdog> disagree
[12:25:54] <pigdog> phb: phrasing issue
[12:26:56] <pigdog> this is 6.3.7
[12:27:14] --- Simon Josefsson has left
[12:27:45] <arvelh> eliot:
[12:27:57] <arvelh> concerned about postponing things in this meeting for too long
[12:28:34] <pigdog> 1383: this document's ultimate fate
[12:28:53] <arvelh> eliot:
[12:29:12] <arvelh> pick one and lets get it done - make it informational document and get the issue closed
[12:29:22] <pigdog> dave crocker:
[12:29:41] <pigdog> getting anything published is a very high barrier
[12:29:48] <pigdog> do we really want to go through it?
[12:29:57] <pigdog> i think this document is useful but not that useful
[12:30:06] <pigdog> paul hoffman: not useful to be an rfc
[12:30:14] <pigdog> let it live as an I-D
[12:30:37] <pigdog> phb: the original idea of the RFC series is to keep a historical record of our decisions
[12:30:53] <pigdog> nothing in the document is normative
[12:31:17] <pigdog> paul hoffman: let's not lecture the IESG on what the series is.
[12:31:31] <pigdog> barry: good record of why we did what we did.
[12:32:05] <pigdog> but we don't need to close this issue today
[12:32:38] <pigdog> stephen: we should not be poking at the document continuously during protocol selection and development
[12:32:58] <pigdog> stephen: agree, but that's independent from whether the doc gets published
[12:33:23] <arvelh> eliot:
[12:33:45] <arvelh> its good to have a historical record of why we did what we did
[12:34:33] --- resnick has joined
[12:34:38] <psavola> Mike: getting the doc at least to the IESG is a way to get "early" feedback on whether the SSP protocol itself is on the right track or not.
[12:34:55] <pigdog> barry: we can lock down the doc as a matter of working group procedure
[12:35:14] --- raeburn has joined
[12:35:38] <pigdog> chairs request opinion from russ
[12:35:40] <pigdog> russ:
[12:35:53] <pigdog> i don't think that feedback from the iesg is what you need or want...
[12:36:07] <pigdog> but what you do need is confirmation from the community that you're on the right track
[12:36:35] <pigdog> you can last calls on things that don't become RFCs (like posting rights removal)
[12:36:49] <pigdog> much cleaner to last call an informational doc
[12:37:14] <pigdog> paul hoffman: another option is to request community input from the ietf mailing list. less overhead
[12:37:31] <pigdog> barry: there are a few area review teams that are now in place
[12:37:59] <pigdog> phb: there are processes here and trying to work around the iesg is not going to help
[12:38:27] <pigdog> if we send our requirements off for last call, when we come up with a specification, then the scopes of comments on our final document is narrower
[12:38:29] --- mrichardson has joined
[12:38:43] <pigdog> you are able to say that you should have commented on last call of the requirements versus protocol
[12:39:16] <pigdog> and you've never locked down the requirements document until you have published the last call of the last document. so locking it down shouldn't be a consideration...
[12:40:10] <pigdog> dave crocker: we should check in with other communities
[12:40:46] <pigdog> russ:
[12:41:05] <pigdog> think about the end state you desire. i really dislike receiving the requirements document and a spec that meets it at the same time
[12:41:31] <pigdog> i prefer the process where the requirements come first, and then a few months or years later the solutions come
[12:41:47] <pigdog> so publish the requirements document when you think it's stable.
[12:42:04] <pigdog> hum
[12:42:18] <pigdog> who wants an informational RFC?
[12:42:47] <pigdog> informational RFC was "more choral"
[12:42:52] <pigdog> but not overwhelming
[12:43:07] <pigdog> jim fenton:
[12:43:21] <psavola> "more choral" than what ?
[12:43:32] <pigdog> more choral than informational draft
[12:43:37] <pigdog> with not publishing
[12:44:01] <pigdog> paul: stop it before it gets to the iesg or let it flow through
[12:44:06] <pigdog> moving on...
[12:44:23] <pigdog> DKIM Policy Proposals
[12:44:26] <pigdog> Phb:
[12:44:42] <pigdog> 3 propopals that can be mixed and matched
[12:44:48] <pigdog> Discovery mechanism
[12:44:57] <pigdog> then how to make the policy much simpler
[12:45:04] <pigdog> and then transitions
[12:45:34] <pigdog> meets all requirements, with possible exception of 6.3 req 7
[12:45:48] <pigdog> Discovery mechanism
[12:46:11] <pigdog> TXT: use bind everything works
[12:46:22] <pigdog> on the other hand wildcards don't work
[12:46:41] <paulwouters@jabber.org> hmm Preview on OSX can't rotate the slides :P
[12:46:41] <pigdog> so you end up with hunt and peck discovery
[12:47:25] <pigdog> so.. use new RR record
[12:47:30] <Stephen Farrell> wouters - any idea what to do about that?
[12:47:43] <pigdog> the problem there is that it requires new DNS servers everywhere?
[12:47:50] <pigdog> this impacts products etc
[12:48:11] <pigdog> and phb has said ms cannot add capabilities due to antitrust concerns
[12:48:16] <paulwouters@jabber.org> stephen: no. I dont have acrobad pdf stuff on my laptop. I am using the "tilting head" method now
[12:48:26] <pigdog> but now we've tied the fate to dns
[12:48:43] <Stephen Farrell> wouters: ok I see the problem, let me see if I can put up the ppt instead (if I have it)
[12:48:48] --- ogud has joined
[12:49:14] <pigdog> option 3: _prefix.example.com, and we special case wildcard records
[12:49:29] <pigdog> wildcards would require upgrade
[12:49:46] <pigdog> PPTR - argument isa DNS node
[12:49:54] <pigdog> does not take a prefix -> wildcard friendly
[12:50:23] <Stephen Farrell> wouters: I replaced the pdf with the ppt try that
[12:50:45] <pigdog> so regardless of how complicated the policy is you can resolve in three steps
[12:50:57] <pigdog> if you don't need a wildcard you have backwards compat with what's out there
[12:51:07] <pigdog> RISC policy
[12:51:21] <pigdog> there is only one policy that actually matters: i always do DKIM
[12:51:29] --- pk has joined
[12:51:29] <pigdog> otherwise the policy does not provide any value
[12:51:37] <pigdog> policy language must be extensible
[12:51:51] --- jakob has joined
[12:52:07] <pigdog> for no mail, or i always use S/MIME, or a reporting mechanism would be an extension
[12:52:20] <pigdog> tag=value sequence
[12:52:29] <pigdog> one policy right now (i do dkim)
[12:52:31] --- mgraff has joined
[12:52:35] <pigdog> why only one policy matters
[12:52:39] <Stephen Farrell> (I'll also replace tony's presentation - the pdf conversion there is sideways too - will take a minute)
[12:52:57] <pigdog> you only look at policy after you fail to find a key record
[12:53:27] <paulwouters@jabber.org> stephen: thanks. much better
[12:53:34] <pigdog> much of this stuff is already in the key record
[12:53:49] <pigdog> so let's not duplicate that
[12:54:11] <mgraff> One note: if you don't make a new record the first look up, you are guaranteeing no one will move past using TXT records. TXT records are a hack, IMHO.
[12:54:24] <pigdog> what if i want to be able to specify exceptions?
[12:55:02] <pigdog> specify a key record for NULL algorithm and add a static header
[12:55:17] --- doug.otis@gmail.com has left
[12:56:24] <pigdog> no policy about "treat these as..."
[12:57:23] --- resnick has left
[12:57:34] <pigdog> policy is for drawing conclusions based on no valid signature
[12:57:51] <pigdog> 3 outcomes
[12:58:04] <pigdog> signed, compliant not signed, not compliant
[12:58:48] <pigdog> signed message might go through whitelist process, for instance
[12:59:13] <pigdog> if it's compliant but not authenticated, perhaps standard spam filtering
[12:59:47] --- dcrocker has left
[13:00:03] <pigdog> not compliant mail provides a range of choices to the recipient
[13:00:23] --- pk has left: Computer went to sleep
[13:01:46] <pigdog> may vary recipient policy based on who is being non-compliant...
[13:02:02] <pigdog> navigating a transition
[13:02:22] <pigdog> so you end up signing twice
[13:02:32] <Stephen Farrell> (Replaced Tony Hansen's presentation with a new pdf if anyone has already downloaded it.)
[13:03:23] <pigdog> if you key record for an unsupported algorithm, then you have to treat signature as as valid
[13:03:40] <pigdog> and that allows for an upgrade attack
[13:04:04] <pigdog> policy must express that we sign twice
[13:04:19] <pigdog> naming the selector
[13:05:17] <pigdog> now listing example
[13:06:07] <pigdog> fake message can be detected only if i have a policy of "i sign twice"
[13:06:15] <pigdog> summary
[13:06:15] --- alexeymelnikov has left
[13:06:33] <pigdog> can significantly reduce complexity even though it's already simple
[13:06:42] <pigdog> meets all requirements
[13:06:47] <pigdog> fully wildcard compatible
[13:06:59] <pigdog> meets unstated requirements
[13:07:23] <pigdog> (navigating a transition)
[13:07:51] <pigdog> doug otis:
[13:08:05] --- weiler has joined
[13:08:13] <pigdog> What does DKIM-Base not accomplish?
[13:08:57] <pigdog> bulk whitelisting, and having other domains sign for your mail
[13:09:28] <pigdog> at present you must exchange keys or some such for providers
[13:09:37] <pigdog> no validation of mailFrom
[13:09:50] <pigdog> that means you're susceptible to replay attacks
[13:10:04] --- dcrocker has joined
[13:10:21] --- pk has joined
[13:10:37] --- weiler has left
[13:10:52] <pigdog> this also means that you would need more keys
[13:11:20] <pigdog> dkim doesn't correlate to a specific SMTP client
[13:11:45] <pigdog> so we need a scheme to associate domains
[13:11:59] <pigdog> create a hash of the domain you want to associate, and publish that into the DNS
[13:12:11] <pigdog> eliminates the need to exchange private keys
[13:12:31] <pigdog> it also means that setting up vanity domains gets cheaper
[13:12:39] <pigdog> it also means that you're free to pick and choose your providers
[13:13:33] <pigdog> also can be used to improve reliability on DSNs
[13:13:47] <pigdog> allows customers to independently set up their dns
[13:14:32] <pigdog> talks about what identities people can associate
[13:15:22] <pigdog> but for from and localpart of from
[13:15:29] <pigdog> hello policy works a little differently
[13:16:16] <pigdog> take a sha1 base 32 encoding of the domain, and then a policy for that entry
[13:16:33] <pigdog> so if you don't find a confirmation on the hash, the d tells you what to do
[13:16:55] <pigdog> a= confirms no collision
[13:18:03] <pigdog> doug discusses each flag
[13:18:30] <pigdog> empty means no mail is sent
[13:18:38] --- patrickn has left
[13:18:45] <pigdog> L contains localpart policy
[13:19:34] <pigdog> trusted designators
[13:19:49] <pigdog> safe annotations can be added as well
[13:20:13] <arvelh> eliot dropped so i'll fill in while he's offline
[13:20:27] <arvelh> originating domains can leverage single dkim sig
[13:20:27] --- pigdog has left
[13:20:27] --- pigdog has joined
[13:20:27] --- pigdog has left
[13:20:43] <arvelh> protects signing domains used for white-listing
[13:20:48] --- pigdog has joined
[13:21:50] <pigdog> by requiring an associating with the smtp client, you can whitelist only when you see the association. otherwise you treat as normal mail
[13:22:23] <pigdog> also it allows people set up relationships as required, you don't have to do key exchange...
[13:22:41] <pigdog> hashing allows you to use UTF in localpart addresses
[13:23:03] <pigdog> minimizes dkim resources
[13:23:49] <pigdog> strong/weak points
[13:24:02] <pigdog> strong: (see previous discussion0
[13:24:23] <pigdog> weak: NXdomain will not end a search for a policy
[13:26:22] <pigdog> complies with all requirements except for 6.3 req 7
[13:27:18] <arvelh> eliot:
[13:27:41] <arvelh> why would I want hash of domain if I already have it
[13:27:59] <arvelh> why bother wish hash if I have the text I'm hashing
[13:28:05] <arvelh> *with hash
[13:28:16] --- mrichardson has left
[13:28:46] <pigdog> answer: hash is the label. you then have a deterministic label size
[13:29:45] <pigdog> dave crocker: was the list of things you listed as not done as (not useful/bad)
[13:29:56] <pigdog> doug: mostly not useful / bad
[13:30:35] --- mrichardson has joined
[13:30:41] <pigdog> (mike debate about whether to answer a meta question)
[13:31:20] <pigdog> jim fenton:
[13:31:43] <pigdog> if i got a message, how many pieces of policy do i actually have to consult?
[13:31:50] <pigdog> doug: left wide open
[13:32:32] <pigdog> it depends on the circumstances as to how much policy is required or stated
[13:32:48] <pigdog> Jim Fenton:
[13:33:32] <pigdog> this is the SSP draft that's been around, but there have been major changes
[13:33:41] <pigdog> now called "sender signing practices"
[13:33:51] --- wouter has left: Logged out
[13:33:58] <pigdog> uses a "custom" DNS RR
[13:34:11] --- glozano has left
[13:34:22] <pigdog> we don't actually have a requirement to solve the bogus subdomain problem
[13:34:40] <arvelh> eliot is down again
[13:34:54] <pigdog> syntax changed
[13:34:54] <arvelh> more human friendly syntax
[13:36:05] <pigdog> why a new RR type?
[13:36:50] <pigdog> so do the lookup of a policy at the same time as perhaps the key or MX records
[13:36:56] <pigdog> the algorithm
[13:37:24] <pigdog> 13 steps looks daunting, but it isn't
[13:37:35] <pigdog> broken down to small steps to make it very clear
[13:38:00] <pigdog> issues relating to parent domains and getting a no data response
[13:38:20] <pigdog> we noticed it because sun.com has a wild card and we'd get a no data with a.b.c.sun.com
[13:38:27] <pigdog> user-level signing practices
[13:38:47] <pigdog> it is an open item as far as the requirements are concerned. if the requirement goes away, this is severable
[13:38:59] <pigdog> i am sitting on the fence about the usefulness of user level signing practices
[13:39:04] <pigdog> so we've made it a separate flag
[13:39:29] <pigdog> previously it was always necessary to go to the user level record for every user
[13:39:42] --- weiler has joined
[13:39:43] <pigdog> now you get the domain level policy and a hint as to whether to go look at the user
[13:40:18] <pigdog> went requirement by requirement as to how they satisfied them
[13:40:42] <pigdog> they do not satisfy 6.3-2
[13:41:14] <pigdog> that would require that practices would need to be checked for every single message
[13:42:07] <pigdog> 6.3.12 conflicts with 6.3.-11 because it's already specified in the key records
[13:42:40] <pigdog> (mthomas take note about conflict ;-)
[13:42:56] <pigdog> clarifying questions
[13:43:09] <thomasm> mike: I know about the conflict, not my fault -- wg needs to resolve this!
[13:43:13] <thomasm> MIKE
[13:43:18] <pigdog> (ack)
[13:44:01] <pigdog> phb: could interpret your yellows as green'
[13:44:10] <arvelh> paul hoffman:
[13:44:16] <arvelh> question for phil
[13:44:32] <arvelh> previously you wanted a generic policy for which we could be the first example
[13:44:56] <arvelh> if WG goes with your proposal will it be generic or dkim specific
[13:45:17] <arvelh> phb:
[13:45:29] <arvelh> designing a system where you don't get the input of the ietf isn't a good idea
[13:45:47] <arvelh> if you can address policy for one protocol it might be useful for other protocols
[13:46:11] <arvelh> creating ptr records for every other protocol would be difficult
[13:46:17] <arvelh> or pptr records
[13:46:48] <arvelh> eliot eliot:
[13:47:18] <arvelh> thought phils presentation well articulated with respect to purpose of protocol and simplicity
[13:47:23] <arvelh> right up until the last slide
[13:47:26] <arvelh> (slides)
[13:47:32] <arvelh> confusing about the "i sign twice"
[13:47:43] <arvelh> are we addressing downgrade attacks using wrong mechanism?
[13:47:58] <arvelh> base says if valid signature exists then use it
[13:48:24] <arvelh> why do we need to go to the effort to protect against this attack?
[13:48:27] <arvelh> phb:
[13:48:41] <arvelh> concerned about exiting the transition process - there's no exit criteria
[13:49:08] <arvelh> if you have policy you want to be able to say "i sign something with a given strength"
[13:49:27] <arvelh> invalid forged messages should not be considered as policy compliant
[13:50:10] <arvelh> believes that this is a clear and important issue
[13:50:14] <arvelh> doug:
[13:50:22] <arvelh> good job phil
[13:50:34] <arvelh> PPTR record is better than previous prosals
[13:50:38] <arvelh> *proposal
[13:50:50] <arvelh> upgrade/downgrade attacks could haunt us in future
[13:50:57] <arvelh> think hard and do it right
[13:51:03] <arvelh> right place to do it is in the keys
[13:51:17] <arvelh> barry:
[13:51:39] <arvelh> if I can handle sha1 but not sha256 and you tell me "i sign twice"
[13:51:44] <arvelh> I can still only verify sha1
[13:52:01] <arvelh> I still wouldn't lknow what to do with the signature that I can't understand
[13:52:19] <arvelh> paul hoffman:
[13:52:37] <arvelh> suggests this is difficult to explain in words but writing it down seems to make it understandable
[13:52:40] <arvelh> phb:
[13:52:53] <arvelh> there are 3 degrees of freedom with possibilities within them
[13:53:04] <arvelh> so there's a matrix of problems/solutions
[13:53:25] --- tonyhansen has left
[13:53:35] <arvelh> "i sign twice" is shorthand for I sign with a key selector that matches this contraint(s)
[13:53:46] <arvelh> to do a key transition divide addresses into various classes
[13:54:00] <arvelh> sometimes you'll use the same key in different selector classes
[13:54:14] <arvelh> have 1 selector for low security alg and another for higher
[13:54:18] <arvelh> barry:
[13:54:35] <arvelh> suppose that stephen is a spammer and he reads your policy and learns to copy your behavior
[13:54:44] <arvelh> so he creates a signature that is bogus and won't verify
[13:54:50] <arvelh> phb:
[13:55:02] <arvelh> if you are using an alg that is definitively broken then, you're "screwed"
[13:55:15] <arvelh> not trying to solve that problem
[13:55:38] <arvelh> adding signatures should never reduce level of security (should be in requirements doc)
[13:56:10] <arvelh> why all the problems with me wanting to add one single flag when the existing has so many already?
[13:56:17] <arvelh> stephen:
[13:56:23] <arvelh> lack of concensus that the new flag is needed
[13:56:31] <arvelh> bob(?)
[13:56:47] <arvelh> comment about expanding ssp to include other groups
[13:56:51] <arvelh> don't go down that road
[13:56:55] <Stephen Farrell> Bob Moskowitz
[13:57:02] <arvelh> we would like to see some wrapup of this work
[13:57:05] <arvelh> dave:
[13:57:28] <arvelh> very hard to transcribe him folks (lol)
[13:57:36] <arvelh> DKIM has lots of good and interesting ideas
[13:57:54] --- Jim Galvin has left
[13:58:02] <arvelh> we tend to dive down into details wituout a clear basis about a problem being solved that we (dkim community) needs to have solved in near term
[13:58:39] <arvelh> having difficulty understanding the assumption of "immediate need"
[13:58:53] <arvelh> why do things have to be solved now? that should be answered first
[13:58:57] <arvelh> mike graff:
[13:59:05] <arvelh> discourage use of wild-card records
[13:59:12] <arvelh> wild cards are not generally understood
[13:59:28] <arvelh> encourage use of specific record for this with TXT as fall back only
[13:59:38] <arvelh> don't want to encourage more use of TXT records
[13:59:55] <arvelh> jim fenton:
[14:00:01] <arvelh> none of proposals use wild-card records
[14:00:10] <arvelh> mostly question of do they function when such records are found
[14:00:14] <arvelh> mike graff:
[14:00:27] --- m_ersue has joined
[14:00:50] <arvelh> unverifiable should be considered unknown
[14:01:13] <pigdog> the other suggestion: why not put policy in the signature headers?
[14:01:24] <pigdog> and dns policy can change out from under you
[14:01:43] <pigdog> barry: a significant part of the policy is what to do when there is no signature
[14:02:02] <pigdog> jim fenton: about expressing a policy about multiple signatures...
[14:02:25] <pigdog> we had discussed whether this is something that should be dealt with in the key record
[14:03:00] <pigdog> we concluded that we don't need the mechanism, and that it solved a non-problem, and so why are we discussing it again in SSP?
[14:03:19] <pigdog> Phb: i was told that this was a policy issue and so i waited until we discussed policy.
[14:03:35] --- pk has left: Computer went to sleep
[14:03:38] <pigdog> stephen: i don't recollect it that way
[14:04:15] <pigdog> phb: the bidding attack is not relevant until you have policy
[14:05:09] <pigdog> doug:
[14:05:32] <pigdog> when we're looking at policy there seems to be a mindset that policy is a hoop that we're going to put spam through
[14:05:59] <pigdog> the concept of trying to block the bad stuff doesn't work
[14:06:17] <pigdog> what needs to be done is how do we defend dkim when we use it? how will it be abused?
[14:06:46] <pigdog> we know we're going to have replay attack, and we know we'd like DSNs delivered. those are the problems we should focus on
[14:06:50] <pigdog> dave crocker:
[14:07:08] <pigdog> dkim pertains to transit rather than long term
[14:07:39] <pigdog> there is concern about bad actors, but not necessarily concern about a bad actor in the sequence.
[14:08:21] --- raeburn has left: Disconnected
[14:08:21] <pigdog> my recollection of the question of the bid down attack was if there was someone in the handling sequence who does that. otherwise, there's an originator or a recipient.
[14:08:31] <pigdog> stephen: the issue is not an MITM attack
[14:08:41] <pigdog> it is someone giving you bogus signatures
[14:09:07] <pigdog> dave: if the signature fails, "that's too bad"
[14:09:55] --- ddayman has left
[14:10:13] <pigdog> concerned that we are revisiting old issues
[14:10:24] <pigdog> that have already been resolved
[14:10:40] <pigdog> stephen: i do not believe this is an old issue
[14:11:04] <pigdog> phb: we agree that a message that has an invalid signature is the same as a message that has a signature that does not verify
[14:11:30] <pigdog> phb: we agree that if a message has no signature when the policy says it should, then it's not compliant
[14:12:08] --- ddayman has joined
[14:12:19] <pigdog> phb: the case is where the attacker can create a message that does not validate but you are unable to validate.
[14:12:41] <pigdog> Tony Hansen
[14:12:49] <pigdog> version 3 of the overview is out
[14:12:52] <pigdog> I'm done ;-)
[14:12:58] <pigdog> just kidding
[14:13:10] --- dcrocker has left
[14:13:17] <pigdog> a variety of implementation considerations are found in the overview
[14:13:40] <pigdog> one of tony's developers: "wow this is great. why didn't you have this written two months ago"
[14:13:58] --- kmurchison has left
[14:14:02] <pigdog> we also talk about ways dkim could evolve in the future
[14:14:06] <pigdog> issues
[14:14:12] <pigdog> when do we push this out?
[14:14:26] <pigdog> do we do it now or do we wait for the ssp discussion to conclude?
[14:14:50] <pigdog> tony would rather keep it on the original schedule
[14:15:08] --- healthyao has joined
[14:15:09] <pigdog> barry: this document is an implementor's guide
[14:15:20] --- pk has joined
[14:15:25] <pigdog> one possibility is to get the document out now and have a separate document later
[14:15:48] <pigdog> paul hoffman: it talks a bit about policy
[14:16:03] <pigdog> barry: hum on getting it out now
[14:16:20] <pigdog> favoring getting it out now but not overwhelming
[14:17:14] <pigdog> issue: doc is big
[14:17:22] <pigdog> some sections need to be filled in
[14:17:32] --- raeburn has joined
[14:17:34] <pigdog> Q & A
[14:17:46] --- jakob has left
[14:18:21] <pigdog> dave crocker: please post comments on individual sections (to help trim doc down)
[14:18:40] --- paulwouters@jabber.org has left: Logged out
[14:18:57] <pigdog> tony: if you have operational experience and please compare your own experience and provide feedback
[14:19:12] <pigdog> barry; purpose is to document why decisions were made, and the other is to help you implement it
[14:19:35] <pigdog> doug: DKIM helps at the MUA
[14:19:47] <pigdog> do you want to delve into what that might mean
[14:19:54] <pigdog> moving on...
[14:20:04] <pigdog> Paul Hoffman
[14:20:12] <pigdog> Vouch by Reference
[14:21:03] <pigdog> purpose is to allow reputation and certification vendors to exchange information about others
[14:21:06] <pigdog> keyed off domain name
[14:21:21] <pigdog> changes since montreal
[14:21:26] --- raeburn has left: Disconnected
[14:21:27] <pigdog> removed selector; wasn't needed
[14:21:39] <pigdog> added domain because people might have multple VBR headers
[14:21:43] <pigdog> we have an online tester
[14:21:52] <pigdog> see paul for details
[14:22:22] <pigdog> questions:
[14:23:03] <pigdog> phb: no modifications to the message. extend key record to point to X.509 cert, with one of those extended certs including logo type etc.
[14:23:54] <pigdog> paul: who are the people who will certify me?
[14:24:18] <pigdog> dave crocker: very similar to csv
[14:25:33] --- ajsaf@jabber.org has left
[14:25:39] <pigdog> paul: low hanging fruit
[14:25:45] <pigdog> going back to the charter now
[14:26:11] <arvelh> barry:
[14:26:20] <arvelh> Tony want to keep exsting date for overview doc
[14:26:31] <arvelh> what date should we put on policy document
[14:26:33] <arvelh> eliot:
[14:26:43] <arvelh> there is no hurry whatsoever for a new DNS rr
[14:26:53] <arvelh> I'm not aware of any work even taking place around that
[14:27:29] <arvelh> SSP proposals include new RR
[14:27:38] --- weiler has left
[14:28:21] --- kurosaki has left
[14:28:21] <arvelh> authors of proposals need time to consider merging proposals or a mechanism needs to be devised whereby we can select a proposal
[14:28:26] <arvelh> can't be done by Dec.
[14:28:31] <arvelh> phil:
[14:28:44] <arvelh> you can mix and match among the various proposals
[14:29:01] <arvelh> June/July
[14:29:04] <arvelh> Dave:
[14:29:10] <arvelh> I might actually agree with Phil!
[14:29:23] <arvelh> I don't see how RR could come out prior to policy spec
[14:29:47] <arvelh> barry: once policy spec is well underway someone could propose a RR spec
[14:29:51] <arvelh> dave:
[14:29:56] <arvelh> lots of proposals on the table
[14:30:09] <arvelh> no WG sequence for a resolution path among the set
[14:30:38] <arvelh> still some need to lock down scope of what we are trying to acomplish - will take time - especially with holidays
[14:30:56] <arvelh> sometime in spring we might be able to lock this down?
[14:31:00] <arvelh> earliest for a reasonable goal would be about June.
[14:31:15] <arvelh> doug:
[14:31:35] <arvelh> regarding RR decisions - my scheme would be compatible with any RR or discovery scheme that we end up with
[14:31:42] <arvelh> eliot:
[14:31:52] <arvelh> it would be unreasonable to not have milestones prior to next IETF
[14:31:57] --- mgraff has left
[14:32:06] <arvelh> milestone should be mechanism and means to arrive at a proposal by next IETF
[14:32:15] <arvelh> Paul:
[14:32:23] <arvelh> barry:
[14:32:53] <arvelh> Russ: don't put goals in list - put "deliverables"
[14:33:05] <arvelh> Barry: July for deliverable for SSP
[14:33:11] <arvelh> dave:
[14:33:31] <arvelh> we do not have a working group document proposal - we could go through a process to choose/create that puts a policy spec as a WG document
[14:34:03] <arvelh> Barry: ok, word-smithing to be done on the list
[14:34:05] <arvelh> eliot:
[14:34:20] --- Barry Leiba has left
[14:34:20] --- Barry Leiba has joined
[14:34:27] --- Barry Leiba has left: Logging off
[14:34:29] <arvelh> some people think SSP is a barrier to adoption so chairs should threaten authors... lol
[14:34:52] --- pk has left: Computer went to sleep
[14:34:57] <pigdog> we are adjourned
[14:35:04] --- pigdog has left
[14:35:05] --- arvelh has left
[14:35:07] --- fenton has left
[14:35:23] --- thomasm has left
[14:36:30] --- ms has left
[14:38:10] --- Stephen Farrell has left: Computer went to sleep
[14:38:51] <rstory> fuck-you
[14:39:14] <rstory> opps, sorry, wrong window! :-/
[14:40:06] --- ogud has left
[14:41:39] --- mrichardson has left
[14:42:00] --- JLCjohn has left
[14:44:22] --- healthyao has left
[14:47:04] --- mrichardson has joined
[14:47:31] --- ddayman has left
[14:47:31] --- ddayman has joined
[14:47:44] --- mrichardson has left
[14:48:31] --- psavola has left
[14:54:37] --- eric has left
[15:12:18] --- john.levine has joined
[15:16:17] --- john.levine has left
[15:21:40] --- ogud has joined
[15:22:13] --- ogud has left: Replaced by new connection
[15:32:59] --- rstory has left
[15:46:26] --- pk has joined
[15:50:00] --- pguenther has left
[15:59:48] --- mrichardson has joined
[16:03:02] --- m_ersue has left
[16:03:56] --- pk has left: Computer went to sleep
[16:16:54] --- pk has joined
[16:18:39] --- pk has left: Computer went to sleep
[16:28:36] --- dcrocker has joined
[16:57:18] --- pk has joined
[17:07:07] --- mgraff has joined
[17:07:13] --- mgraff has left
[17:16:43] --- dcrocker has left
[17:17:32] --- pk has left
[17:22:59] --- mrichardson has left
[17:26:17] --- mrichardson has joined
[17:38:01] --- pk has joined
[17:45:06] --- pk has left: Replaced by new connection
[17:45:06] --- pk has joined
[17:59:12] --- pk has left: Computer went to sleep
[18:17:24] --- healthyao has joined
[18:21:38] --- healthyao has left
[18:22:07] --- pk has joined
[18:50:14] --- pk has left
[23:14:35] --- mrichardson has left
[23:14:36] --- mrichardson has joined