[02:26:54] --- dcrocker has left: Replaced by new connection
[02:26:54] --- dcrocker has joined
[02:26:54] --- dcrocker has left
[02:39:32] --- dcrocker has joined
[03:27:56] --- pk has joined
[03:28:08] --- pk has left
[05:06:04] --- frank has joined
[05:11:49] --- frank has left: Logged out
[06:08:16] --- frank has joined
[07:33:37] --- frank has left
[08:57:03] --- sftcd-at has joined
[08:57:43] * sftcd-at has set the topic to: Sep. 28th DKIM Meeting in 2 hours
[10:06:08] * sftcd-at has set the topic to: Sep. 28th DKIM Meeting in bit under an hour
[10:15:58] --- john.levine has joined
[10:16:53] --- john.levine has left: Lost connection
[10:17:39] --- john.levine has joined
[10:18:22] --- jrlevine has joined
[10:18:30] --- john.levine has left
[10:18:30] --- pigdog has joined
[10:18:52] <pigdog> good afternoon
[10:19:29] <ddayman> morning
[10:30:49] * sftcd-at has set the topic to: Sep. 28th DKIM Meeting in about half an hour
[10:30:51] <sftcd-at> hi guys
[10:34:23] <pigdog> good afteroon
[10:45:58] * sftcd-at has set the topic to: Sep. 28th DKIM Meeting in about 15
[10:51:49] --- fenton has joined
[10:51:59] <fenton> hi folks
[10:53:23] --- doug.otis@gmail.com has joined
[10:53:31] --- sftcd-at has left: Replaced by new connection
[10:53:32] --- sftcd-at has joined
[10:55:42] --- dcrocker has left
[10:58:16] --- dcrocker has joined
[10:58:27] --- dcrocker has left
[10:58:42] --- dcrocker has joined
[10:58:46] --- dcrocker has left
[10:58:53] --- tonyhansen has joined
[10:58:57] --- dcrocker has joined
[10:59:22] * sftcd-at has set the topic to: Sep. 28th DKIM Meeting starting
[10:59:24] <tonyhansen> good morning, day, evening, early morn
[10:59:39] <sftcd-at> Hi all, ready to start? (stop shuffling those chairs at the back:-)
[10:59:49] <sftcd-at> Agenda as usual is:
[10:59:50] <sftcd-at> #1 agenda bash (2 min) #2 ssp-reqs issues and requirements (50) #3 further jabber session logistics (5) #4 AOB
[11:00:03] <sftcd-at> And I think we agreed to run for 90 minutes today
[11:00:17] <sftcd-at> Summary of last time is http://mipassoc.org/pipermail/ietf-dkim/2006q3/006055.html
[11:00:25] --- thomasm has joined
[11:00:42] <sftcd-at> Issue tracker: https://rt.psg.com/Search/Results.html?Order=ASC&Query=Queue%20%3D%20'dkim'%20AND%20(Status%20%3D%20'open'%20OR%20Status%20%3D%20'new')&Rows=50&OrderBy=id&Format=
[11:01:12] <sftcd-at> So, item 1: agenda bashing - I think we should add "review actions" - that ok?
[11:01:21] <pigdog> +1
[11:01:52] <sftcd-at> For 1201/1207 arvel did write some text - anyone got it handy?
[11:02:51] <sftcd-at> Got it: "Expectations MUST be presented in the Protocol syntax using as intuitive a descriptor as possible. For example, p=! would be better represented as p=strict."
[11:03:04] <sftcd-at> Is that ok to include and then close 1201/1207?
[11:03:31] <fenton> I like it
[11:03:36] <dcrocker> +1
[11:03:42] <doug.otis@gmail.com> Not a good idea from the standpoint of ensure a compact record.
[11:03:59] <thomasm> I would recommend use terms that haven't been poisoned
[11:04:11] <thomasm> strict in particular
[11:04:21] <ddayman> +1
[11:04:25] <sftcd-at> that's easy: s/strict/foo/
[11:04:29] <fenton> I think he's just saying that strict is more intuitive than !
[11:04:46] <fenton> foo isn't very intuitive...
[11:04:55] <doug.otis@gmail.com> But uses more record space for little actual value.
[11:05:03] <dcrocker> we are not choosing the words. we are stating a principle.
[11:05:04] <pigdog> but it seems to me that intuition requires a something meaningful
[11:05:05] <thomasm> intuitive of what? There are many different interetations of "strict"
[11:05:12] <sftcd-at> Doug - there's an "if possible" there so if record size is an issue (it may be) then SSP might end up with terse strings
[11:05:33] <sftcd-at> Mike - strict in this case is just an example we can pick any.
[11:05:38] <doug.otis@gmail.com> With DNS size always matters.
[11:05:40] <pigdog> right
[11:05:41] <tonyhansen> I'm less concerned about record size
[11:05:48] --- pk has joined
[11:05:48] <tonyhansen> ... for this issue
[11:05:59] <fenton> Tiny +1
[11:06:06] <pigdog> doug: we're not talking about key records. how large are these things going to be?
[11:06:06] <doug.otis@gmail.com> This will be extended in the future.
[11:06:07] <fenton> Tony +1 I mean!
[11:06:20] <ddayman> he
[11:06:24] <tonyhansen> been a long time since anyone called me "tiny" :-)
[11:06:25] <doug.otis@gmail.com> It is better to remain concervative.
[11:06:46] <doug.otis@gmail.com> Why use +1?
[11:06:48] <tonyhansen> conservative, but not cryptic
[11:07:02] <sftcd-at> Any other points against inclusion (assuming a better example is used)?
[11:07:05] <pigdog> we were concerned about key length in the key records because we know that over time the keys have to double in size.
[11:07:08] <doug.otis@gmail.com> S versus ! perhaps?
[11:07:20] <pigdog> or grow geometrically or something like that
[11:07:39] <pigdog> i don't see that as a problem here
[11:07:54] <sftcd-at> Any other points ?
[11:07:56] <fenton> There is a tradeoff between compact and intuitive, this just says that intuitiveness is important
[11:08:02] <dcrocker> at this point, i
[11:08:23] <dcrocker> at this point, i've lost track. is anyone opposed, other than doug?
[11:08:48] <doug.otis@gmail.com> Letters would be better than !~#$%
[11:09:04] --- sftcd@jabber.org has joined
[11:09:06] <pigdog> and words are better than letters.
[11:09:12] <pigdog> if they can be descriptive
[11:09:20] <doug.otis@gmail.com> Not when space matters.
[11:09:25] <pigdog> but does it?
[11:09:30] <thomasm> my only objection is using things like "strict" because it's not clear
[11:09:32] <pigdog> what's the specific argument here?
[11:09:32] <sftcd-at> (I seem to have dropped out for a bit.)
[11:09:38] <doug.otis@gmail.com> It might.
[11:09:51] <doug.otis@gmail.com> The question already takes up a fair amount of the answer.
[11:09:59] <sftcd-at> I see a rough consensus for including this with a different example.
[11:10:04] <dcrocker> thomas, we are not choosing the words. we are stating a principle.
[11:10:06] <tonyhansen> sf: +1
[11:10:12] <doug.otis@gmail.com> The answer may confirm components of the question.
[11:10:24] <doug.otis@gmail.com> When all that is added, there is really not much room.
[11:10:43] <sftcd-at> Mike will you fix the example? and Eliot can close 1201.1207
[11:11:16] <doug.otis@gmail.com> I put together a scheme that allowed all originating fields to have a policy. The question does take up most the answer.
[11:11:23] <fenton> Maybe use "unknown" as the example. That's less controversial.
[11:11:31] <sftcd-at> Doug - we're done on this one.
[11:11:53] <thomasm> which example was that?
[11:12:12] <sftcd-at> s/strict/unknown/ in Arvel's sentence (as suggested by Jim)
[11:12:30] <fenton> and probably also s/!/?/
[11:12:46] <thomasm> can you guys just send me the text you want :)
[11:12:53] <sftcd-at> Jim?
[11:13:06] <fenton> just a sec
[11:13:49] <fenton> "Expectations MUST be presented in the Protocol syntax using as intuitive a descriptor as possible. For example, p=? would be better represented as p=unknown."
[11:14:15] <sftcd-at> Ok then. That's to go in somewhere and 1201/1207 are to be CLOSED.
[11:14:25] <thomasm> I suppose that that should really be Practices/Expectations, right
[11:14:26] <doug.otis@gmail.com> Or unk?
[11:14:36] <tonyhansen> unknown, not unk
[11:14:43] <sftcd-at> Next action was Dave and Mike to work on some text for 1357. Did that happen?
[11:14:49] <fenton> let's not try to design the syntax in the requirements phase
[11:15:06] <sftcd-at> 1357 is "what's the diff between 4.1 and 4.2"
[11:15:10] <thomasm> somewhat
[11:15:25] <sftcd-at> Do you want to say that now or send to the list?
[11:15:40] <thomasm> somewhat we did clarify some aspects of the scenarios
[11:15:55] <thomasm> and I have some notes that I need to incorporate
[11:16:00] <doug.otis@gmail.com> This is where a defined state is needed.
[11:16:39] <sftcd-at> Mike - so maybe send that text to the list and we can move on right now leaving the issue open?
[11:16:49] <thomasm> I've decided to subcategorize the scenarios into "problem" scenarios and "deployment" related scenarios
[11:17:01] <thomasm> yes, that sounds right
[11:17:11] <sftcd-at> Ok 1357 still open then.
[11:17:25] <sftcd-at> Those were the only actions I think.
[11:17:47] <sftcd-at> So back to the issues list. We ended up last time discussing 1360...
[11:18:35] <doug.otis@gmail.com> This was to add a section better describing the used of designation versus delegation.
[11:19:18] <fenton> We need to answer a higher-level question, whether designation/delegation is {needed, good, desirable, etc.}
[11:19:20] <doug.otis@gmail.com> While I understand there are those that want to see just delegation, it would be better to define both in the requirements.
[11:19:44] <dcrocker> no, it would not necessarily be better
[11:19:54] <doug.otis@gmail.com> That might be better answered later.
[11:20:12] <sftcd-at> I don't think we inclusivity is as good approach for requirements - less is more here right (except for those things we do want)
[11:20:15] <thomasm> The question I have to the group is whether I've captured the pros and cons adequately
[11:20:20] <doug.otis@gmail.com> This is fairly early in the design phase.
[11:20:20] <dcrocker> if we are 'requiring' added mechanism for dkim but do not actually need it, then adding it to requirements is problematic.
[11:20:44] <fenton> IIRC, the designation idea originally came about as an easier way to accomplish delegation, and they aren't the same thing.
[11:21:01] <fenton> Do we agree that the semantics of the two are different?
[11:21:07] <sftcd-at> So for now delegation means what?
[11:21:21] <doug.otis@gmail.com> Right, but designation can scale and is safer from several prespectives.
[11:21:42] <doug.otis@gmail.com> DNS delegation or the exchange of keys.
[11:21:50] <fenton> Delegation is the ability to give a signing key to someone else, and make it look like you signed it.
[11:22:03] <doug.otis@gmail.com> Designation would be simply the use of a name.
[11:22:10] <sftcd-at> Is it worth differentiating between exchange of keys and DNS methods?
[11:22:16] <fenton> Designation is the ability for someone else's signature to be recognized as a first-party sig
[11:22:30] <thomasm> Here's my big question: Is this a problem without which was have an unworkable protocol? And if we need to at a later date could add in if there was a proven need?
[11:22:37] <thomasm> My sense is that we really don't know
[11:22:46] <doug.otis@gmail.com> Designation simply mean a method of saying treat this signature as being the same as this domain.
[11:22:56] <fenton> Delegating keys vs. NS records is just the mechanics of doing delegation, semantically the same
[11:23:11] <dcrocker> if the choice is between having a dns point vs. exchanging a selector key, then they both are already supported. What is needed to be added as a "requirement"?
[11:23:32] <fenton> Right. The question is whether we need designation too.
[11:24:00] <doug.otis@gmail.com> A method that does not involve either DNS delegation or the exchange of keys.
[11:24:04] <sftcd-at> Do we all agree with what Jim just said?
[11:24:08] <thomasm> yes
[11:24:46] <doug.otis@gmail.com> When this needs to scale into the tens of thousands, delegation or the exchange of keys will be an impediment.
[11:25:01] <doug.otis@gmail.com> designation will not be an impediment.
[11:25:13] <doug.otis@gmail.com> One cost far less as well.
[11:25:20] <fenton> Doug: Do you agree that delegation and designation have different semantics?
[11:25:43] <fenton> If you do, then one isn't a substitute for the other.
[11:25:48] <doug.otis@gmail.com> Somewhat, but as the draft that I wrote attempts to explain, they are not that different.
[11:26:01] <doug.otis@gmail.com> Both can achieve the same result.
[11:26:11] <doug.otis@gmail.com> Designation does it for less.
[11:26:26] <doug.otis@gmail.com> Cost and ease will be an issue.
[11:26:33] <fenton> Depends on what you mean less of, I suspect.
[11:27:00] <doug.otis@gmail.com> Less labor?
[11:27:00] <fenton> This is the draft you pointed out this morning?
[11:27:10] <doug.otis@gmail.com> Yes.
[11:27:13] <sftcd-at> Anyone else here also want designation? (There were others on the list as I recall)
[11:27:19] <jrlevine> Seems to me that we already have delegation, we know that it works for DK because people use it. How about not adding more features?
[11:27:24] <doug.otis@gmail.com> Sorry, but I was working of several things at once.
[11:27:37] <thomasm> jlr +1
[11:28:06] <doug.otis@gmail.com> Delegation via DNS or keys involves three parties, designation involves only one.
[11:28:12] <thomasm> s/jlr/jrl
[11:28:40] <doug.otis@gmail.com> I would not describe delegation for DKIM as something that we know works on a large scale.
[11:29:01] <doug.otis@gmail.com> I suspect we will find the opposite to be true.
[11:29:03] <sftcd-at> So we seem to have rough consensus here that deleegation is sufficient. We need to validate that on the list I think.
[11:29:13] <jrlevine> We know it works on a large scale for DK, large mailers use it. Enough already.
[11:29:22] <sftcd-at> Can someone take an action to summarise this and post to the list?
[11:29:38] <fenton> I'll do that
[11:30:09] <sftcd-at> Thanks Jim. So we can leave 1360 open for now, but heading for a CLOSE/REJECT if the list confirm the consensus that designation isn't a requirement.
[11:31:08] <doug.otis@gmail.com> Just for the record, by large scale, this was to mean many users and not large users.
[11:31:13] <sftcd-at> (Chair hat off for a second) I will be raising an issue later about key management - but maybe not until the protocol work, i.e. after reqs.
[11:31:46] <sftcd-at> My issue is basically that if we are suggesting key based delegation there's an onus on us to say how to do that at least one "secure" way.
[11:31:58] <thomasm> stephen -- I assume that that means that the provisional status of req #5 is settled as well?
[11:32:00] <doug.otis@gmail.com> agreed.
[11:32:08] <sftcd-at> (Chair hat on again)
[11:32:25] <sftcd-at> Mike - have to go look - do you want to cut'n'paste here?
[11:32:46] <thomasm> 5. [PROVISIONAL] A domain MUST be able to delegate responsibility for signing its messages to a non-related domain in such a way that it does not require active participation by the non-related domain. That is, the published information MUST have a way to specify the domains that are allowed to sign on its behalf.
[11:33:10] <thomasm> I believe that this was what people were calling "designated"
[11:33:37] <sftcd-at> Sounds like it? So if 1360 goes to CLOSED/REJECT then Mike can also delete that provisional requirement. That ok?
[11:33:45] <doug.otis@gmail.com> Yes, but there is no usage scenario for this.
[11:34:03] <doug.otis@gmail.com> I do not like that conclusion.
[11:34:07] <sftcd-at> which?
[11:34:16] <thomasm> yes there was scenario 3
[11:34:27] <doug.otis@gmail.com> Deleting the requirement for designated.
[11:34:32] <dcrocker> " in such a way that it does not require active participation by the non-related domain." is a considerable requirement. I do not understand why it is essential, ie, a requirement.
[11:35:16] <thomasm> Well, that's the way it started out life until it was discovered that it couldn't work that way
[11:35:20] <thomasm> ala Jim's attack
[11:35:36] <sftcd-at> Doug - I understand, but if 1360 is a REJECT then that provisional req also goes I think. Can folks who agree with that say so?
[11:35:57] <fenton> Agree
[11:36:16] <doug.otis@gmail.com> The attack would not be a problem when the goal is annotation.
[11:36:19] <thomasm> they seem coupled to me -- requirement 5's aim was what people were calling designation
[11:36:31] <thomasm> so +1 stephen
[11:36:32] <doug.otis@gmail.com> The goals involved should not be based upon blocking messages.
[11:36:40] <sftcd-at> Ok - Jim can you make that clear in your note to the list then.
[11:36:45] <sftcd-at> Moving on...
[11:37:00] <sftcd-at> 1361 - commentary...
[11:37:41] <doug.otis@gmail.com> Little of this commentary appears to be valid or belong in the req draft.
[11:37:41] <thomasm> is this now moot?
[11:37:55] <sftcd-at> that's what I was wondering.
[11:38:00] <thomasm> My plan is to remove this section altogether
[11:38:08] <doug.otis@gmail.com> good.
[11:38:49] <sftcd-at> So 1361 is a CLOSE/ACCEPT/MOOT since the provisional reqiurement disappears and so also the entire section 5.3.1.
[11:38:55] <sftcd-at> That ok with us all?
[11:38:59] <pigdog>
[11:39:10] <thomasm> speak, pigdog!
[11:39:31] <pigdog> i'm there
[11:39:42] <sftcd-at> Moving on again...
[11:39:44] <pigdog> i don't close issues other than dups in the jabber sessions.
[11:39:45] <fenton> We need to confirm the consensus on removing the provisional requirement first, but yes.
[11:39:48] <pigdog> that happens later
[11:39:59] <sftcd-at> 1362
[11:39:59] <pigdog> but i do record the decisions
[11:40:03] <sftcd-at> (agreed Jim)
[11:40:26] <sftcd-at> 1362 is Problems with Scenario 4: Resent
[11:40:48] <dcrocker> 1362 is part of the re-work of scenarios that Thomas is doing.
[11:41:12] <sftcd-at> So should we postpone discussion here?
[11:41:35] <dcrocker> yes
[11:41:43] <thomasm> maybe my action is to rework this text algtogether and send it to dave
[11:41:50] <doug.otis@gmail.com> Is there any interest in reviewing he differences between blocking and annotation with respect to policy reqs?
[11:42:18] <doug.otis@gmail.com> It seem much of the current effort is based upon blocking.
[11:42:23] <sftcd-at> Doug - raise an issue first.
[11:42:34] <dcrocker> but not right now
[11:42:38] <dcrocker> we have an agenda
[11:42:41] <dcrocker> let's follow it
[11:42:51] <sftcd-at> So we leave 1362 open pending Dave/Mike reworking the scenarios text
[11:43:01] <doug.otis@gmail.com> This is really in regard to how designation helps with annotation without the risks that Jim raised.
[11:43:39] <sftcd-at> So 1363 SSP: Discover "requirement"
[11:44:25] <fenton> This seems like a good set of fundamental principles
[11:44:30] <thomasm> so would the solution here to have a deployment scenario up above to motivate this dave?
[11:44:49] <fenton> I think you're already motivating much of this
[11:44:59] <doug.otis@gmail.com> Looking at the amplification potential would also be a good thing to mention.
[11:45:10] <fenton> and it's hard to write a scenario that motivates the extensibility piece
[11:45:25] <dcrocker> scenarios are a good start, but a 'requirements' statement must not rely on it for defining what is being required.
[11:45:46] <dcrocker> so if we are to have requirements pertaining to discovery, we need to say what is being discovered.
[11:46:03] <doug.otis@gmail.com> The scenarios help by providing an example.
[11:46:11] <dcrocker> more generally, we need requirements that are conceptual, before we have requirements that specify mechanics.
[11:46:20] <thomasm> right, this is what I was thinking about adding for a "deployment scenario" type of motivation
[11:47:23] <sftcd-at> so... it sounds like 1363 is heading for an ACCEPT but what's the action to change and who's doing it?
[11:47:38] <thomasm> I think it's my action, Stephen
[11:47:42] <dcrocker> state what is being discovered.
[11:48:00] <sftcd-at> Good.
[11:48:31] <sftcd-at> Just while we're there - that section looks fine but its odd that 5.1 says "MUST be DNS" and 5.2 is transport reqs.
[11:48:43] <pk> I miss bounding principles for discovery such as that arbitrary DNS tree climbing is avoided.
[11:49:07] <dcrocker> name administration, versus information query. both can be DNS, but they don't have to be.
[11:49:15] <dcrocker> we can have domain names, without DNS query.
[11:49:35] <sftcd-at> ps: doesn't 5.1 req2 help there?
[11:49:43] <doug.otis@gmail.com> One must consider how the traffic might amplify as it passed through a sequence of MTAs and MUAs.
[11:49:57] <sftcd-at> sorry meant "pk," not "ps"
[11:50:51] <thomasm> Note that what I'm trying to say in t.1 is that the information ROOT must be DNS (ie, not some other third party)
[11:51:06] <fenton> The need for tree climbing is a concern regardless if the publication mechanism is DNS or not
[11:51:16] <thomasm> I tried not to presuppose DNS as being the repository for the actual data though
[11:51:17] <fenton> Because if it's not, you still need DNS to find it...
[11:51:35] <pk> just the number is not enough, since that's likely bound by 127 anyway. The danger is getting out of your own area (to avoid "domain" of control). I don't see how to prevent that other than setting the limit to 0 or 1 (depending on how you count).
[11:51:43] <doug.otis@gmail.com> One dns transaction to find a server?
[11:52:00] <sftcd-at> pk: can you raise a separate issue on that?
[11:52:19] <pk> yes
[11:52:42] <sftcd-at> Thanks. So 1363 is headign for ACCEPT and Mike has the action to incorporate/change accordingly.
[11:52:51] <sftcd-at> Moving on. 1364...
[11:53:03] <thomasm> hold on... I'm not sure what I'm changine
[11:53:12] <sftcd-at> Moving back...
[11:53:13] <dcrocker> Base Discovery Requirement: Receivers need a means of obtaining information about sender DKIM practices. This requires a means of discovering where the information is and what it contains."
[11:53:43] <dcrocker> (took too long to type. move my posting on base discovery to the list.)
[11:53:49] <doug.otis@gmail.com> Is that touching the third rail?
[11:54:00] <sftcd-at> So we're back on 1363. Who wants to say what Mike should be changing.
[11:54:21] <thomasm> dave this is yorus? can you just send me text of what you think needs done?
[11:54:36] <dcrocker> thomas - yes
[11:54:39] <thomasm> k
[11:54:46] <pigdog> +1
[11:54:55] <sftcd-at> Good. So Mike & Dave together have the action for 1363.
[11:55:06] <sftcd-at> Now onto 1364 - Generic requirements for SSP, v1.
[11:55:53] <fenton> Oops - just discovered that I was looking at the wrong issue during the last discussion!
[11:56:05] <fenton> Pls forgive any non-sequiturs
[11:56:23] <sftcd-at> Dave suggested 3 generic reqs. Any problem with including these?
[11:56:41] <sftcd-at> 1. SSP is an extension of the DKIM message signing service. 2. The DKIM message signing service can be more useful, if potential signers have the ability to notify receive-side processing services about the constraints under which the potential signer sends mail. This permits distinguishing conformant messages from non-conformant messages. 3. SSP needs an extensible publication mechanism, to permit incremental definition of practices
[11:56:42] <thomasm> dave -- do you think that this should be part of the introduction?
[11:57:07] <doug.otis@gmail.com> As email is store and forward, where is negotiations are not practical. The policy can offer two choices and indicate which is deprecated.
[11:57:08] <sftcd-at> or even the abstract
[11:57:32] <fenton> As I said before, this is a good set of fundamental principles
[11:57:36] <dcrocker> I think an introduction should not contain requirements. all 3 of these are requirements. 1 & 3 quite explicitly. 2 more conceptually.
[11:57:37] <sftcd-at> Doug: Huh?
[11:57:55] <sftcd-at> So this would be 5.0 or something?
[11:58:05] <dcrocker> I think of it more as 0.5.
[11:58:14] <dcrocker> basic requirements should preceded detailed requirements.
[11:58:25] <pigdog> dave +1
[11:58:28] <thomasm> I'm pretty sure that your 3 is already in the requirements
[11:58:44] <thomasm> as well as 1 and 2
[11:58:49] <pigdog> more to the point, principles should either precede or be precede basic requirements
[11:58:50] <sftcd-at> Anyway I sense consensus to include these and leave it to Mike to slot 'em in the right place. OK?
[11:58:57] <fenton> OK
[11:59:01] <pigdog> ok
[11:59:04] <dcrocker> +1
[11:59:15] <sftcd-at> So 1364 is an ACCEPT with the editor to do stuff.
[11:59:17] <thomasm> well, If I can point out where they are covered and send it to the list is that ok?
[11:59:35] <dcrocker> thomas -- let's talk about this offline.
[11:59:39] <sftcd-at> works for me, see what the list says
[11:59:41] <pigdog> my time is up- catch you guys later
[11:59:52] --- pigdog has left
[12:00:01] <sftcd-at> So 1365, typos from Frank.
[12:00:34] <sftcd-at> But its not about typos, its about non-typos.
[12:00:39] <sftcd-at> 5.4: Are (1) and (3) in conflict ? Maybe join (1)+(3). I dont's see the MUST in (4), it's a "nice to have".
[12:01:46] <doug.otis@gmail.com> I have no objections.
[12:02:00] <doug.otis@gmail.com> to these changes that is.
[12:02:30] <sftcd-at> Anyone else on the putative 5.4 change?
[12:03:30] <sftcd-at> Nope - so we heading to ACCEPT and hence ask the editor to reword 5.4 then.
[12:03:47] <sftcd-at> What about his 2nd point: 5.3 (2): IIRC we've identified "never send mail" as a special case of "strict", and then just not sending mail, let alone signing it. IMO you can delete this point.
[12:04:26] <thomasm> delete which point?
[12:04:28] <sftcd-at> He's suggesting deleting " 2. The Protocol MUST be able to publish a Practice that the domain doesn't send mail."
[12:04:48] <doug.otis@gmail.com> That would be a nice to have.
[12:04:55] <fenton> I vote to delete that 5.3(2) as well.
[12:05:01] <dcrocker> +1
[12:05:21] <sftcd-at> Sounds like a consensus.
[12:05:35] <thomasm> I have some heartburn about this as it's the _one_ thing that A receiver can take very harsh action on
[12:06:07] <dcrocker> the issue is not the policy, but whether it needs a special publication mechanism.
[12:06:08] <thomasm> if we want to say that SSP does something, this is an extremely non-controversion use
[12:06:25] <dcrocker> as a special case of strict, we do not need an added, specific, mechanism
[12:06:27] <fenton> Understand, but 5.3(2) isn't a *signing* practice
[12:06:37] <doug.otis@gmail.com> It is in a sense.
[12:06:48] <sftcd-at> I'm with Jim there I have to say.
[12:07:01] <doug.otis@gmail.com> This says invalid signatures are not mine in a very positive way.
[12:07:27] <thomasm> I feel rather uncomfortable about the algebraic nature of this argument
[12:07:31] <fenton> too many negatives there
[12:07:58] <thomasm> this should be based on whether there's utility to the receiver
[12:08:16] <doug.otis@gmail.com> With respect to DKIM overhead, there could be.
[12:08:16] <sftcd-at> So we have a couple of voices against deleting 5.3(2) and maybe 4 for deleting. Not a clear consensus. Anyone else?
[12:08:50] <doug.otis@gmail.com> A long lived policy replaces always looking for a missing key.
[12:09:12] <sftcd-at> No-one else it seems for now anyway.
[12:09:41] <sftcd-at> I think we have to bring 5.3(2)'s deletion back to the list. Who wants to send the mail?
[12:10:41] <fenton> don't all type at once
[12:11:01] <sftcd-at> Yes - who's gotten no actions so far...How about you Doug?
[12:11:28] <doug.otis@gmail.com> Okay I'll post something about 5.3.(2)
[12:12:06] <sftcd-at> Good. So 1365 stays open. Mike to reword 5.4 a bit and Doug to bring the lack of consensus on the chat wrt. 5.3(2) to the list.
[12:12:10] <sftcd-at> Moving on...
[12:12:21] <doug.otis@gmail.com> Ha.
[12:12:33] <sftcd-at> 1366: Definition of "DKIM Signer Complete"
[12:12:57] <sftcd-at> Was there more traffic on this on the list?
[12:13:13] <thomasm> I've been thinking about this for a while, and I think that the current definition is actually right
[12:13:21] <thomasm> I don't think there was stephen
[12:13:40] <sftcd-at> must be me being confused.
[12:13:53] <doug.otis@gmail.com> I don't see 1366 in the issues list.
[12:14:06] <sftcd-at> Oops - its 1367 -sorry
[12:14:45] <sftcd-at> Anyone else care about this or should we just let Mike and Arvel arm-wrestle?
[12:14:52] <fenton> I think Arvel's right -- why would someone publish a policy saying to expect a signature from someone else?
[12:14:58] <thomasm> "signing complete" seems to me that it means that you sign all mail with an origination address that corresponds to your domain
[12:15:10] <thomasm> Sender: for example
[12:15:15] <doug.otis@gmail.com> Do not agree to this change.
[12:15:20] <fenton> Mike: That's first party then, right?
[12:15:35] <thomasm> doesn't matter... SSP is an information service at its base
[12:15:39] <fenton> (except I don't understand the Sender reference)
[12:15:52] <thomasm> Sender: foo@example.com
[12:15:56] <thomasm> where you own example.coim
[12:16:39] <thomasm> If I want to find out whether example.com signs everything, nothing prevents me from using SSP to do that
[12:16:44] <sftcd-at> A light bulb just popped into existence over my head anyway
[12:16:55] <doug.otis@gmail.com> The policy can indicate which signatures are valid as well.
[12:17:22] <doug.otis@gmail.com> While designation is not being considered now, it might be in the near future.
[12:17:42] <sftcd-at> So jim - you still like the change?
[12:17:45] <doug.otis@gmail.com> Add this constraint to a basis definition is not needed.
[12:18:04] <fenton> I think so, but should probably chat with Mike about it
[12:18:20] <thomasm> I'll be in after this...
[12:18:42] <sftcd-at> So there's a rough consensus on the chat to REJECT 1367.
[12:18:51] <doug.otis@gmail.com> good.
[12:18:53] <sftcd-at> Moving on.
[12:19:20] <sftcd-at> 1369 Invoking SSP - Suggestion to Remove this.
[12:19:50] <sftcd-at> Didn't hector subsequently post suggested wording?
[12:20:00] <thomasm> not that I understood it
[12:20:02] <doug.otis@gmail.com> I think that he did.
[12:20:29] <sftcd-at> 1.1 Invoking SSP How SSP is invoked is out of scope of the SSP requirements. The design for SSP implementation and usage may vary depending on the mail application. For example, a SMTP receiver may wish to invoke SSP immediately to check for various policies prior to performing the higher overhead DKIM-BASE has verification process. A LIST SERVER may wish to invoke SSP as part of its subscription process. It should be noted that valid 1st party signatures is considered to be a sufficiently secured valid condition per DKIM-BASE specification design goals which may allow for DKIM-SSP implementators a method to short circuit SSP queries when 1st party signatures are valid. However, implementators should keep in mind, it is technically possible for an inconsistent policy to exist even for valid 1st party signatures. How implementators address this condition is out of scope of the SSP requirements.
[12:20:41] <doug.otis@gmail.com> There are possible scenarios and uses at the MUA where this limitation may not want to apply.
[12:20:43] <sftcd-at> (that's hector's text - sorry if its crap in your client)
[12:21:24] <thomasm> well going from one sentence to 3 paragraphs gives some pause
[12:21:39] --- ddayman has left
[12:21:56] <sftcd-at> There was also some discussion on the list
[12:22:12] <sftcd-at> that was tending towards a REJECT I think.
[12:22:30] <thomasm> yeah, this seems more like a misunderstanding
[12:22:32] <fenton> I disagree with Hector that it's out of scope. How SSP is structured, and if by nature it requires consultation even in the presence of a valid orig sig, affects the efficiency of the protocol.
[12:22:59] <sftcd-at> So we have a rough consensus for the current wording and to REJECT 1369 then?
[12:23:12] <thomasm> +1
[12:23:16] <doug.otis@gmail.com> There are more than one place where policy might be used.
[12:23:18] <fenton> yes, rej 1369
[12:23:30] <sftcd-at> Doug - is that a yes or no to what I asked?
[12:23:55] <doug.otis@gmail.com> I would say there is a point in removing and agreeing with Hector on this.
[12:24:20] <sftcd-at> Anyone else?
[12:24:21] <doug.otis@gmail.com> At the MTA, I would agree with Jim.
[12:24:53] <sftcd-at> Does someone need to raise an issue about that "at the MTA" point?
[12:24:55] <doug.otis@gmail.com> At the MUA, I tend to agree with Hector for different reasons.
[12:25:15] <sftcd-at> (I don't see that "SSP at the MUA" is a requirement for us now basically)
[12:25:17] <fenton> Doug, I don't understand that comment at all.
[12:25:41] <doug.otis@gmail.com> DKIM is not limited to be acted upon at only the MTA.
[12:26:01] <sftcd-at> Sure. But are we now writing requirements for how to use SSP at the MUA or not?
[12:26:17] <sftcd-at> Doesn't our charter say something on this?
[12:26:19] <doug.otis@gmail.com> DKIM can also be verified at the MUA and this is a strong reason why it is better than path registration.
[12:26:37] <doug.otis@gmail.com> DKIM works in both places. Policy should as well.
[12:26:54] <thomasm> well, I for one have no clue as to how this relates to #10
[12:26:59] <doug.otis@gmail.com> The time-stamp may not include the IP address for example.
[12:27:01] <fenton> How does this point affect whether SSP works at the MUA?
[12:27:13] <dcrocker> MUA vs. MTA: DKIM does not require being based in the MTA. We need to make sure that we do not have functions that force the processing venue.
[12:27:22] <doug.otis@gmail.com> The actions at the MUA are annotation based.
[12:27:35] <fenton> Not really
[12:27:40] <doug.otis@gmail.com> This changes the character and motivations for checking policy.
[12:28:03] <doug.otis@gmail.com> There may be a desire to see if there is something special about foo@
[12:28:15] <thomasm> Doug. Can you give a concrete thing that this requirement would prevent you from doing?
[12:28:19] <sftcd-at> So there's confusion. Can someone take an action to raise an issue to clarify this? (pretty please?)
[12:28:25] <fenton> When I say "DKIM works at the MUA" I mean that the MUA actually verifies the signature, potentially checks SSP, etc.
[12:28:49] <sftcd-at> (we're at 1 minute to go btw )
[12:29:05] <doug.otis@gmail.com> The MUA is also able to provide clear annotations related to establishing trust.
[12:29:28] <thomasm> what does that have to do with 10?
[12:29:31] <doug.otis@gmail.com> This may involve only trusting the domain or trusting an email-address.
[12:29:43] <thomasm> what does that have to do with 10?
[12:29:46] <sftcd-at> Ok. The MUA/MTA thing we'll maybe have to revisit, but let's park it for this chat.
[12:29:48] <doug.otis@gmail.com> The need to query when 10 says don't
[12:29:57] <thomasm> false
[12:30:10] <sftcd-at> On 1369 - I still see rough consensus for a REJECT.
[12:30:20] <sftcd-at> And that brings us to AOB?
[12:30:27] <sftcd-at> Any Other Biz then?
[12:30:28] <thomasm> it doesn't say that you may not, just that in the face of a signature the protocol must not REQURIE it
[12:30:44] <fenton> Next jabber chat is when?
[12:30:48] <sftcd-at> If not, then I'll summarise to the list and same time next week.
[12:31:05] <fenton> Good meeting, thanks everyone
[12:31:09] <thomasm> thanks all
[12:31:23] <sftcd-at> Bye for now.
[12:31:30] <doug.otis@gmail.com> Bye
[12:31:33] <dcrocker> bye
[12:31:36] --- doug.otis@gmail.com has left
[12:31:40] --- xyz has joined
[12:31:47] <tonyhansen> bye
[12:31:53] --- sftcd-at has left
[12:31:56] --- tonyhansen has left
[12:32:03] <pk> bye
[12:32:05] --- pk has left
[12:32:13] --- xyz has left
[12:33:06] --- fenton has left
[12:34:35] --- hls has joined
[12:36:42] --- jrlevine has left
[12:38:12] --- sftcd-at has joined
[12:39:55] --- hls has left
[12:40:05] --- sftcd-at has left
[12:40:21] --- sftcd@jabber.org has left
[12:52:52] --- hls has joined
[12:55:06] --- thomasm has left
[12:58:18] --- hls has left
[13:36:34] --- dcrocker has left
[13:36:51] --- dcrocker has joined
[13:37:00] --- dcrocker has left
[13:38:27] --- dcrocker has joined
[13:38:31] --- dcrocker has left
[16:13:30] --- LOGGING STARTED
[16:15:40] --- jpope has joined
[16:16:04] <jpope> checking for log sync
[16:16:09] --- jpope has left
[16:49:12] --- frank has joined
[16:50:19] --- frank has left
[16:50:34] --- frank has joined
[16:58:16] --- frank has left
[17:32:24] --- doug.otis@gmail.com has joined
[17:33:03] --- doug.otis@gmail.com has left: Lost connection
[17:34:49] --- doug.otis@gmail.com has joined
[17:34:58] --- doug.otis@gmail.com has left
[22:47:55] --- john.levine has joined
[22:48:01] --- john.levine has left
[22:48:21] --- john.levine has joined
[22:48:29] --- john.levine has left