[10:41:37] --- eric has joined
[10:58:53] --- sm-msk has joined
[11:05:22] --- sm-msk has left
[11:08:18] --- eric has left
[11:11:04] --- ogud has joined
[11:11:21] --- ogud has left
[12:46:57] --- doug.otis@gmail.com has joined
[14:11:09] --- sm-msk has joined
[14:21:46] --- sm-msk has left
[15:15:44] --- frank has joined
[15:16:28] --- frank has left
[15:32:42] --- ryu has joined
[15:32:49] --- ryu has left
[15:44:36] --- sm-msk has joined
[15:48:41] --- sm-msk has left
[15:55:50] --- joncallas has joined
[15:58:20] --- thomasm@jabber.psg.com has joined
[16:05:00] --- thomasm@jabber.psg.com has left
[16:05:15] --- doug.otis@gmail.com has left
[16:05:37] --- mike@mtcc.com has joined
[16:06:29] --- eric has joined
[16:06:31] --- gshapiro has joined
[16:16:21] --- arnt has joined
[16:17:36] --- sm-msk has joined
[16:17:49] --- eliot.lear has joined
[16:18:23] <eliot.lear> good afternoon. this is the DKIM working group. the meeting has not yet come to order.
[16:18:37] <eliot.lear> i'll be scribing for a good portion of this meeting
[16:18:38] --- ddayman has joined
[16:18:44] --- jlcjohn has joined
[16:20:23] --- fenton has joined
[16:21:44] --- shpark has joined
[16:21:47] --- arvelh@jabber.org has joined
[16:22:19] <eliot.lear> If you wish to have something spoken into the microphone, please preface your comment with "MIC:"
[16:22:53] --- pawal has joined
[16:23:13] --- doug.otis@gmail.com has joined
[16:24:13] --- ryu has joined
[16:24:47] <eliot.lear> we are ready to begin
[16:24:59] --- cnewman@jabber.org has joined
[16:25:17] <eliot.lear> stephen:
[16:25:21] <eliot.lear> agenda bashing
[16:25:38] <eliot.lear> any bashes?
[16:25:53] <eliot.lear> no bashes
[16:26:01] <eliot.lear> doc status
[16:26:11] <eliot.lear> rfrc 4871 is out the door
[16:26:19] <eliot.lear> it would be nice to see some usage statistics
[16:26:54] <eliot.lear> draft-ietf-dkim-ssp-reqs-04 out of last call
[16:27:19] <eliot.lear> tim (ad):
[16:28:10] <eliot.lear> a few last call comments and one discuss to clear. should not be difficult
[16:28:28] <eliot.lear> "we're there!!"
[16:29:07] <eliot.lear> fixing the security considerations section will need more text...
[16:30:15] <eliot.lear> eliot: be careful not to allow solutions engineering
[16:30:24] <eliot.lear> tim; agree.
[16:30:44] <mike@mtcc.com> I'm on line
[16:31:06] <eliot.lear> moving on...
[16:31:17] <doug.otis@gmail.com> There should be concerns reviewed in the SSP reqs regarding how SSP might help deal with compromised keys in shared servers.
[16:31:25] <eliot.lear> draft-ietf-dkim-ssp-00
[16:31:35] <eliot.lear> jim fenton
[16:32:12] <sm-msk> re-stating earlier note from the scribe:
[16:32:17] <sm-msk> (13:22:19) eliot.lear: If you wish to have something spoken into the microphone, please preface your comment with "MIC:"
[16:32:51] <eliot.lear> changes from pre-wg draft... removed user level granularity
[16:33:06] <eliot.lear> SSP published as prefixed TXT records
[16:34:22] <eliot.lear> since SSP requirements wanted tags to be human readable, change tag p -> dkim
[16:35:00] <eliot.lear> this is the third try for a lookup algorithm for not only the domain for which the policy is published, but also the policy for subdomains
[16:35:20] <eliot.lear> no wildcards because of txt records
[16:35:23] <sm-msk> (attempt at a compromise between wildcard and search)
[16:35:47] <eliot.lear> compromise on tree walking - and we'll get to that in a bit
[16:35:59] <eliot.lear> What's not new
[16:36:16] <eliot.lear> did not include XPTR
[16:36:25] <eliot.lear> all of this based on WG consensus
[16:36:36] <eliot.lear> phil has a draft
[16:36:54] <eliot.lear> phil, what is the status of that draft?
[16:36:55] <eliot.lear> phb:
[16:37:14] <eliot.lear> basically, where it will go depends on what i discuss with the dns folk this week
[16:37:32] <eliot.lear> dnsext is officially dormant but rechartering, so it MAY make sense to put it there or not
[16:37:38] <eliot.lear> jim:
[16:37:48] <eliot.lear> no third party authorization
[16:38:11] <eliot.lear> (example.com uses another company or domain to distribute mail)
[16:38:26] <eliot.lear> doug otis has written a draft
[16:38:49] <doug.otis@gmail.com> It is compatible
[16:38:51] <eliot.lear> stephen farrell: is doug's draft compatible?
[16:39:04] <doug.otis@gmail.com> It can be added without changes to SSP.
[16:39:16] <doug.otis@gmail.com> It is just an extension.
[16:39:30] --- bruce has joined
[16:39:31] <eliot.lear> still no nomail policy
[16:39:53] <eliot.lear> do we have some other way that we can express the same thing without nomail?
[16:40:10] <eliot.lear> Section 5 Third Party Signatures and Mailing Lists
[16:40:22] --- kasumigaura has joined
[16:40:58] <eliot.lear> jim: perhaps section 5 belongs in the overview
[16:41:14] <eliot.lear> eliot: doesn't that get us right into the normative text issue in the -overview?
[16:41:16] <eliot.lear> jim: yes
[16:41:40] <eliot.lear> stephen: we do not have a consensus that nomail is not in scope.
[16:42:11] <eliot.lear> draft-hallambaker-nomail-00.txt describes an extension to do nomail
[16:42:13] <eliot.lear> 4 pages
[16:42:23] <eliot.lear> (that was phb)
[16:42:29] <eliot.lear> Jim:
[16:42:39] <eliot.lear> Wildcards have been an issue
[16:43:08] <eliot.lear> we can't publish wildcards with prefixes
[16:43:19] --- Stephen Farrell has joined
[16:43:53] <doug.otis@gmail.com> MIC: you can detect a domain by using only SMTP discovery records.
[16:44:00] <eliot.lear> if any parent has a wildcard, you no longer get an NXDOMAIN
[16:44:27] <sm-msk> what's an SMTP discovery record?
[16:44:33] <doug.otis@gmail.com> That would be MX or A
[16:44:43] <mike@mtcc.com> senders don't need an MX
[16:44:44] <eliot.lear> peter koch: i didn't understand that
[16:45:07] <doug.otis@gmail.com> A valid domain will have a means to send to it, as well as send.
[16:45:18] --- resnick has joined
[16:46:19] <eliot.lear> phb: if you're looking for cases where you're sending mail from a server that doesn't have a domain on the internet, there is no need for wildcarding dkim policy records, but rather you can handle it with a nomail policy
[16:46:46] <eliot.lear> one goal is to handle proper subdomains, such as sub.example.com and host.example.com
[16:47:05] --- guenther has joined
[16:47:21] <eliot.lear> in a flat domains space you want to not require a record per host
[16:47:59] <eliot.lear> chair: please hold discussion until later, but perhaps {clarifications are okay}
[16:48:10] <eliot.lear> peter koch: why?
[16:48:41] <eliot.lear> jim: additional administrative work, organizational issues..
[16:49:04] <eliot.lear> jim: it's not a zone size issue.
[16:49:18] <doug.otis@gmail.com> Obsolete A record discovery and only use MX records for discovery would be a solution at some point in the future.
[16:49:23] <eliot.lear> peter: it's a provisioning issue
[16:49:37] --- hallam has joined
[16:50:00] <eliot.lear> barry: the people who manage mail have concerns about the people who manage dns getting this right
[16:50:21] <eliot.lear> even so it won't help his organizations
[16:50:44] <eliot.lear> peter: i'm a bit concerned about these kind of provisioning issues influencing the architectural decisions about the name space
[16:50:59] <eliot.lear> jim: let's hold on to that idea and see if we made reasonable tradeoffs
[16:51:03] <Stephen Farrell> peter: do bring that up again when Jim's at the end please
[16:51:41] <eliot.lear> here's the lookup algorithm
[16:52:39] <eliot.lear> alternatives:
[16:53:41] <eliot.lear> - "climb the tree". potential for make work attack with a.b.c.d.e.f.g.h.j.k.l.m.n.o.p.q.example.com
[16:53:50] <eliot.lear> another alternative
[16:53:53] <eliot.lear> 2nd possibility:
[16:54:22] <eliot.lear> if you find the domain exists and there's no ssp record, then you assume there is no policy, and you use "the default policy" that it signs some of its mail
[16:54:49] <eliot.lear> you would then need to publish an ssp record alongside every host in your domain
[16:55:02] <eliot.lear> the third choice:
[16:55:28] <eliot.lear> if the domain exists and SSP record doesn't, ascend one layer only
[16:56:00] <eliot.lear> murray: what about a top down approach?
[16:56:08] <eliot.lear> starting with com, co.uk, ...
[16:56:39] <eliot.lear> peter: there is no authoritative list as what is a TLD
[16:57:22] <eliot.lear> phb: this is the reason why barry's use case as to why the administrative interface to DNS is so important
[16:57:50] <eliot.lear> if we assume administrative hierarchy reflects the naming hierarchy, it makes DNS inflexible and brittle
[16:59:24] <eliot.lear> phb: any algorithm that is predicated c.b.a, that b.a has any ownership rights for c.b.a makes things break in ways that are unpredictable.
[16:59:44] <eliot.lear> assuming you can travel up the tree or down the tree is bad juju
[17:00:10] <eliot.lear> there will be a similar discussion in the HTTP bof
[17:00:23] <doug.otis@gmail.com> Agreed.
[17:00:25] <eliot.lear> peter koch: searching in the dns doesn't work well
[17:00:26] <doug.otis@gmail.com> Always checking a parent domain will impact various domains used to register domains, such as SLDs.
[17:00:46] <eliot.lear> and now the algorithm
[17:00:55] <eliot.lear> there is now a flow chart on the screen
[17:01:05] <eliot.lear> there are no loops
[17:02:27] <eliot.lear> always look to see if you have a valid signature? if so, the message is non-suspicious
[17:02:32] <eliot.lear> stop
[17:02:39] <eliot.lear> assuming you don't, then ssp
[17:03:36] <eliot.lear> query for _sso._domainkey.ORIGINATING-ADDRESS-DOMAIN
[17:03:49] <eliot.lear> if a valid SSP record, then implement what that record says to do
[17:04:29] <eliot.lear> otherwise, query to determine if OAD exists
[17:04:44] <eliot.lear> if NXDOMAIN, message is suspicious
[17:05:15] <eliot.lear> otherwise, optionally query the parent's ssp record
[17:05:48] <doug.otis@gmail.com> MIC: Why not include a check for an MX to better protect SLDs?
[17:05:49] <eliot.lear> if you don't get a valid record, non-suspecious
[17:05:58] <eliot.lear> otherwise, follow policy
[17:07:33] <eliot.lear> jim: because of legacy issues with A records
[17:07:45] <doug.otis@gmail.com> At least it could curtail a fair amount of traffic, nevertheless.
[17:08:17] <mike@mtcc.com> MIC: with a text record, could we still make normative behavior on the resolver to, say, they SHOULD send additional RR's with the second lookup?
[17:08:19] <eliot.lear> the chance that you have a cache hit on an MX is high
[17:08:27] --- secastro_scl has joined
[17:09:38] <eliot.lear> jim: i'm not fussy about txt. could as for mx or a or srv
[17:09:48] <eliot.lear> peter: mike, let's take that offline
[17:09:51] <eliot.lear> dave crocker:
[17:10:19] <eliot.lear> the mx has me a bit confused when it gets brought into a discussion like this, since mx are for receive-side, and this is abou querying back to the send side
[17:10:25] <doug.otis@gmail.com> Is the domain valid is being asked?
[17:10:40] <mike@mtcc.com> ie, the A records
[17:10:56] <eliot.lear> jim: the idea was just to find a record that was likely to be in the cache, and txt is less likely to be in the cache than an MX record
[17:11:24] <eliot.lear> additional questions?
[17:11:28] <eliot.lear> barry:
[17:11:29] --- pk has joined
[17:12:20] <eliot.lear> if there's no ssp record, at the originating address domain, and that domain gives an NXDOMAIN on the record, then it's suspicious - or if policy indicates all mail is signed, then it's suspicious
[17:12:28] <pk> mike: what did you mean by "with the second lookup"? responding with the SSP information piggybacked on the TXT response?
[17:12:44] <mike@mtcc.com> jim's second lookup required a separate query
[17:12:48] <eliot.lear> next slide
[17:12:56] <eliot.lear> max 3 dns lookups required
[17:13:02] <eliot.lear> removes some administrative overhead
[17:13:12] <mike@mtcc.com> if you put the results in the additional RR's, you could avoid that lookup
[17:13:13] <eliot.lear> interprets non-existent domains as suspicious
[17:13:31] <eliot.lear> and existing domains that don't have an SSP records are not suspicious
[17:13:59] <eliot.lear> sikmple records within SSP domains don't require SSP records because it's resolved by the parent
[17:14:00] <pk> but there is no context for DNS queries, so the resolver would behave this way for every TXT (FOO, BAR, ...) query
[17:14:20] <eliot.lear> but if you hve a.b.example.com, you would need to publish a specific record.
[17:14:27] <pk> even more so, there's no way to add a positive information to a negative response
[17:14:35] <mike@mtcc.com> it is under the _domainkey subtree... but yes that's true
[17:14:36] <eliot.lear> moving on
[17:14:49] <eliot.lear> what can ssp convey?
[17:15:21] <eliot.lear> there was a lot of concern early on requiring something on behalf of the recipient.
[17:16:03] <eliot.lear> but we do have some domains, like banks, that in fact want to be able to see suspicious mail dropped
[17:16:14] <eliot.lear> sorry 0-
[17:16:20] <eliot.lear> s/dropped/marked suspicious/
[17:16:23] <Stephen Farrell> eric allman at the mic
[17:16:42] <eliot.lear> jim:
[17:17:33] <eliot.lear> strict means that only I as the domain owner can sign my mail. d=i=
[17:17:48] --- eliot.lear has left
[17:18:17] <Stephen Farrell> eliot dropped out, anyone else take up the scribing?
[17:18:18] <sm-msk> there are two different things: policies and expectations. this is more about the latter.
[17:18:27] --- eliot.lear has joined
[17:18:30] <sm-msk> so far we've been talking about suspicious vs. non-suspicious
[17:18:41] <sm-msk> now we're describing what suspicious means; what to do when you get something suspicious
[17:18:44] <sm-msk> back to you eliot
[17:18:58] <eliot.lear> thanks! sorry about that
[17:19:10] <doug.otis@gmail.com> MIC: When some sub-domain are considered "authoritative" for acceptance "assessments", (per overview draft) this too should be included as an aspect of SSP records. Would this required an "assessment permissive" flag as this precludes strict flags at the parent?
[17:19:34] <eliot.lear> barry: signing domain still gives advice to the verifyier
[17:20:16] <Stephen Farrell> doug - the question is too complicated
[17:20:44] <eliot.lear> this is the flipside of that..
[17:21:26] <eliot.lear> so we have some large banks going to some large ISPs, and pleading that they drop unsigned mail. that speaks strongly to the need for a protocol
[17:22:24] <eliot.lear> dave crocker:
[17:22:46] <eliot.lear> a continuing challenge that we have in this space is that we know that there are some very strong desires that want to deal with some very serious problems
[17:23:17] <eliot.lear> what seems to me not as clear is what are the dynamics of the mechanisms will be in the wild. what keeps concerning me here there is no precident on the internet.
[17:23:40] <eliot.lear> jim: there's a difference between asking and expecting
[17:23:44] <eliot.lear> some of them will follow
[17:24:24] <eliot.lear> dave: the idea of publishing a statement of "here's how I'd like you to behave" we don't have a track record of doing that.
[17:24:35] <Stephen Farrell> eliots out again
[17:24:57] <Stephen Farrell> dave: some confusing expectattions appear to being set
[17:25:10] <Stephen Farrell> dave: so we should be less elaborate not more
[17:25:37] <Stephen Farrell> dave: even for minimal thing, we need to understand what the market wants, and that they understand what they'll get
[17:25:49] <Stephen Farrell> dave: "the market" isn't here, so he's worried
[17:25:59] <Stephen Farrell> barry: has this been discussed at maawg and apwg?
[17:26:18] <Stephen Farrell> dave: stuff like this has been discussed at maawg, but not explained in detail
[17:26:35] <Stephen Farrell> jim: pat peterson might have discussed at maawg
[17:26:49] <Stephen Farrell> eliot (from the mic): was at maawg, discussion was v. high level
[17:26:50] <doug.otis@gmail.com> MIC:A track record might look really bad when dealing with a compromised server requires the listing of thousands of domains. This really demands the use of Third-party authorization and not transparent exchanges of keys.
[17:27:01] <Stephen Farrell> eliot: uucp is a precedent
[17:27:16] <Stephen Farrell> eliot: agrees with dave that starting small then expanding is better
[17:27:31] <Stephen Farrell> eric: "strong" could be called "extreme"
[17:28:01] <Stephen Farrell> eric: flow-chart - as laid out, if you extend the set of policies then you default to suspicious if the SSP client doesn't know the extension
[17:28:02] <eliot.lear> bob morgan:
[17:28:36] <eliot.lear> there is small scale practice in SAML and there is a lot of work being done in the security space regarding security policy
[17:28:47] <eliot.lear> i see this reaction a lot, when there is non-trivial policy
[17:29:14] <eliot.lear> phb: the key here is that policy must always be declarative and not imperative
[17:29:20] --- tonyhansen has joined
[17:29:59] <eliot.lear> the reason is that you want to keep the imperative out is that you are stuck with one set of use cases and one set of requirements and you can't then extend, adapt, and survive
[17:30:40] --- tlr has joined
[17:30:58] <eliot.lear> i would rather what this is saying speak more plainly
[17:32:03] <eliot.lear> (jim) the reason i've come around to an imperative is that there could be inconsistency of implementation
[17:32:17] <eliot.lear> for example, soft fail and hard fail in SPF has a wide range of responses
[17:33:31] <eliot.lear> phb: the reason you use declarative is that when you take this information and put it in the context of other information, i cannot establish a motivation behind it.
[17:33:41] <eliot.lear> and this might provide more choices for recipients
[17:33:56] --- arnt has left
[17:34:05] --- joncallas has left: Replaced by new connection
[17:34:26] <eliot.lear> dave crocker: the comment "i don't want my domain name spoof" was very crisp. it's an example of a whole bunch of things one might want
[17:34:35] <eliot.lear> dave: i don't want to be phished...
[17:35:12] <eliot.lear> each mechanism is expensive to implement on an internet scale
[17:35:25] --- joncallas has joined
[17:36:16] <Stephen Farrell> ACTION: Dave C/PHB: go to maawg & apwg and find out what practices they want and if there's a match with this
[17:37:15] <eliot.lear> stephen: what affect would this have in the real world?
[17:38:06] <eliot.lear> stephen: the concern is how many times you would go down each branch
[17:38:32] <eliot.lear> murray: this would trivially added to our stuff, we can provide real statistics.
[17:38:49] <doug.otis@gmail.com> Much of the query traffic could be curtailed by including MX records as evidence of domain existence.
[17:38:53] <eliot.lear> but there aren't enough dkim policy records
[17:39:13] --- bruce has left
[17:39:29] <eliot.lear> jim: in the short term you'll need to do between 2 and 3 queries
[17:40:01] <mike@mtcc.com> MIC: the important part here is how well on average caching makes this a local lookup
[17:41:54] --- Stephen Farrell has left: Replaced by new connection
[17:41:54] --- Stephen Farrell has joined
[17:42:27] <Stephen Farrell> jim: there are others who'd know better but it depends on the min ttl
[17:42:40] <eliot.lear> msn might not give an SSP record.
[17:43:02] <eliot.lear> tony hansen: overview
[17:43:04] <doug.otis@gmail.com> MIC: As a security WG, it is rather common to find hundreds of thousands of HTTP servers compromised. This may impact SMTP outbound servers containing DKIM private keys. is an area not well handled by not having a means to explicitly authorize the signing domain. The value of this form of protection may be hard to assess until DKIM becomes highly problematic.
[17:43:57] <sm-msk> roger.
[17:44:32] <doug.otis@gmail.com> Okay.
[17:45:44] <eliot.lear> that was the liberty bell march
[17:46:22] <eliot.lear> overview document provides an overview of dkim
[17:46:33] <eliot.lear> recent changes
[17:46:35] <sm-msk> write that down
[17:46:58] <eliot.lear> based on feedback, a framework. how this thing fits together. 2nd part goes into deployment
[17:47:15] <eliot.lear> not many comments
[17:47:32] <eliot.lear> doc has a 32 pages
[17:47:58] <eliot.lear> framework is 12 pages, ops practices is 14 pages
[17:48:33] <eliot.lear> base spec is nice and succint, but it's way to low level
[17:48:40] <eliot.lear> need something else
[17:50:24] --- bruce has joined
[17:50:44] <eliot.lear> Federal Trade Commission started asking all sorts of loaded questions, all low level stuff, and the stuff he should have been asking about was the stuff that's in the overview document
[17:51:00] <eliot.lear> issues
[17:51:24] <eliot.lear> how can it fit into a message service?
[17:52:05] <eliot.lear> issue relating to normative text. is it informational or what?
[17:52:12] <eliot.lear> doc contains normative language
[17:52:30] <eliot.lear> stephen: charter says informational. why should we change that?
[17:52:49] <eliot.lear> jim fenton: i view the base document how to apply a signature and verify it on a message
[17:53:09] <eliot.lear> it doesn't address things like messages with mutliple signatures.
[17:53:31] <eliot.lear> there are a lot of practices that warrant some normative language, and i think there's room for another document
[17:53:31] <doug.otis@gmail.com> MIC: The overview further extends a concept of DNS hierarchal management. It adds "assessment" sub-domains, without DKIM base having a means to control this "feature." This feature has not been well reviewed in respect to security, and is causing much of the "normative" language. These details should be described in a BCP draft instead.
[17:53:46] --- secastro_scl has left
[17:54:15] --- tonyhansen has left
[17:54:52] <Stephen Farrell> eliot goes to mic
[17:55:02] <Stephen Farrell> dave c: we have started getting feedback, thanks
[17:55:37] <Stephen Farrell> dave: some of the normative language duplicates base and/or ssp and will be fixed/deleted from overview
[17:55:58] <Stephen Farrell> dave: some normative sutff goes beyond what we really know and should also be fixed
[17:56:17] <Stephen Farrell> dave: but that leaves some normative statements that are real and based on real experience
[17:56:45] <Stephen Farrell> me: do you have an example
[17:57:14] <Stephen Farrell> dave: comments on the draft are too recent - will do that later, but since there might be we need to be careful
[17:57:26] <Stephen Farrell> eliot: agrees in part with Doug's conclusion,
[17:57:57] <Stephen Farrell> eliot: may be room for a BCP and an informational document
[17:58:07] <Stephen Farrell> eliot: if 14 pages contian the overview then ...
[17:58:17] <Stephen Farrell> eliot: ... why not take that out and leave the rest?
[17:58:47] <Stephen Farrell> eliot: maybe start a BCP draft with the rest (e.g. mailing list issues) as a separate document
[17:58:57] <Stephen Farrell> tim polk (AD): agrees with Eliot
[17:59:03] <doug.otis@gmail.com> Agreed.
[17:59:13] <Stephen Farrell> tim: probably less danger in putting out informational and BCP separately
[17:59:44] <Stephen Farrell> tim: if you're ready to start a BCP that should be separate and he'd prefer us to re-charter for that
[17:59:49] <Stephen Farrell> tim: BCP might of course take longer
[18:00:05] --- =JeffH has joined
[18:00:17] <Stephen Farrell> tim: if we try change the intended state people may re-read much more critically (be careful)
[18:00:28] <eliot.lear> pete resnick:
[18:00:47] <eliot.lear> if you're going to two documents, and i agree two documents is a good thing to do, going to bcp doesn't seem right
[18:01:10] <eliot.lear> maybe use an applicability statement and go through the normal standards process
[18:01:38] <eliot.lear> as a side note, the iesg needs to {provide guidance} on what goes to bcp and what goes through the standards track
[18:01:39] <eliot.lear> tim:
[18:01:58] <eliot.lear> we're aware that this is something that needs to be clarified
[18:02:19] <eliot.lear> dave crocker has agreed that we would split the document
[18:02:43] <eliot.lear> sorry- correction
[18:02:56] <eliot.lear> dave has said that if the docs are split we have editors
[18:03:43] <eliot.lear> tim: it may turn out that we have best current practices now that we should get out now
[18:04:30] <Stephen Farrell> just to note that the overview editors just signed in blood that they'd finish the standards-track document if we do a split:-)
[18:04:50] <eliot.lear> another view of the overview
[18:05:02] <Stephen Farrell> (these slides are from Prague)
[18:05:11] <eliot.lear> prague slides are up
[18:05:52] <eliot.lear> tony: sense of the room is the prague direction
[18:05:54] <Stephen Farrell> http://www3.ietf.org/proceedings/07mar/slides/dkim-2/sld1.htm
[18:06:05] <eliot.lear> first piece is part one of the current doc
[18:06:13] <eliot.lear> 2nd piece is part two of the current doc
[18:06:20] <Stephen Farrell> (back to today's slides)
[18:06:22] --- dperkins3600 has joined
[18:07:35] <eliot.lear> jim fenton: if you do the informational document first, is there anything you might want to describe there that we don't have normative language for?
[18:07:57] <eliot.lear> do you think you have enough normative language to say what you want to say in the descriptive document?
[18:08:26] <eliot.lear> are there things that we need to have normative language for that we don't that would be necessary to make the informational portion complete?
[18:08:39] --- dperkins3600 has left
[18:08:45] <mike@mtcc.com> MIC: as somebody who's been in the trenches, I'm dubious that we have enough yet for a bcp and normative -- let's not rush this
[18:09:36] --- ryu has left: Replaced by new connection
[18:09:37] --- ryu has joined
[18:09:51] <eliot.lear> tony:
[18:09:56] <eliot.lear> we need more eyeballs
[18:10:38] <mike@mtcc.com> let's not add more normative until we have experience in general, Stephen
[18:11:09] <eliot.lear> by next week we should be able to split out the overview
[18:12:09] <eliot.lear> process issues: how do we recharter?
[18:12:40] <eliot.lear> tim: need new text in the charter
[18:12:56] --- ddayman has left
[18:12:59] <eliot.lear> tony will take action item to provide text
[18:13:08] <eliot.lear> murray:
[18:13:47] <eliot.lear> auth-results is about to go to -05. this is a new header field to be used to produce results of validation, so that it can be used as a filtering decision.
[18:13:48] --- Stephen Farrell has left: Replaced by new connection
[18:13:49] --- Stephen Farrell has joined
[18:14:26] <Stephen Farrell> eliot: auth-res is nice in what it communicates, couple of issues thought with using a header field
[18:14:49] <Stephen Farrell> eliot: draft requires inbound MTA to strip, but non participating one won't be able to do that
[18:15:00] <Stephen Farrell> eliot: need advice to MTAs for handling that in a safe manner
[18:15:08] --- arvelh@jabber.org has left
[18:15:09] <Stephen Farrell> eliot: there're also MTA config issues
[18:16:04] <Stephen Farrell> eliot: 3rd issue: might make sense to put this in e.g. ESMTP or IMAP, and that might impact on where to work on this
[18:16:07] <doug.otis@gmail.com> MIC: How can these results be securely conveyed? There are backup MTAs where things are different. This needs to be signed by the receiving domain.
[18:16:18] <Stephen Farrell> dave C: eliot: who's hair?
[18:16:38] --- cnewman@jabber.org has left: Replaced by new connection
[18:16:40] --- eliot.lear has left
[18:16:44] <Stephen Farrell> murray: might want to sign new header
[18:16:57] <doug.otis@gmail.com> Yes.
[18:18:09] <doug.otis@gmail.com> If it is signed, then DKIM would be logical.
[18:19:05] --- bruce has left: Logged out
[18:19:12] --- jlcjohn has left
[18:19:14] --- pawal has left
[18:19:23] --- fenton has left
[18:19:25] --- resnick has left
[18:19:26] <doug.otis@gmail.com> Bye
[18:19:27] --- =JeffH has left
[18:19:30] --- eric has left
[18:19:34] --- kasumigaura has left
[18:19:35] --- doug.otis@gmail.com has left
[18:19:47] --- Stephen Farrell has left: Computer went to sleep
[18:19:56] --- gshapiro has left
[18:19:57] --- ryu has left: Computer went to sleep
[18:20:12] --- hallam has left
[18:21:43] --- sm-msk has left: Logged out
[18:22:35] --- mike@mtcc.com has left
[18:23:56] --- shpark has left
[18:26:33] --- shpark has joined
[18:36:18] --- tlr has left
[18:36:23] --- pk has left
[18:48:00] --- shpark has left
[19:00:37] --- joncallas has left
[19:14:50] --- guenther has left
[19:51:20] --- pk has joined
[20:20:18] --- pk has left: Computer went to sleep
[20:20:27] --- pk has joined
[21:44:33] --- pk has left
[23:38:24] --- shpark has joined
[23:45:07] --- hallam has joined