[05:03:29] --- dcrocker has left: Replaced by new connection
[05:03:29] --- dcrocker has joined
[05:03:29] --- dcrocker has left
[08:33:38] --- nealmcb has joined
[08:55:02] --- Eliot.Lear has joined
[08:56:01] --- Eliot.Lear has left
[09:00:55] --- nealmcb has left
[09:00:57] --- nealmcb has joined
[09:42:33] --- Eliot.Lear has joined
[10:19:22] --- sftcd has joined
[10:19:37] * sftcd has set the topic to: DKIM meeting in 40 mins
[10:19:53] <sftcd> hi eliot, neal
[10:19:57] <Eliot.Lear> hi there... you going to update that every minute?
[10:20:00] <Eliot.Lear> ;-)
[10:20:23] <sftcd> neal - what brings you here today?
[10:21:01] <sftcd> perhaps he's lurking...
[10:21:20] <sftcd> eliot - what's the story on the issues list - haven't looked last day or so
[10:21:41] <Eliot.Lear> not so bad. i haven't added doug's last issue, nor have i added my nit
[10:21:53] <Eliot.Lear> however, if we review...
[10:21:59] <Eliot.Lear> (give me a moment to get there)
[10:22:38] <Eliot.Lear> am i okay to close sha-1 -> sha-256?
[10:22:42] <Eliot.Lear> (1185)
[10:23:52] <sftcd> yep, believe so
[10:24:27] <Eliot.Lear> ok, i'll close it. i think that goes with 1196, which is "base: upgrade indication and protection against downgrade attacks"
[10:24:51] <sftcd> me too - I'm sure we nixed those on an earlier jabber (going looking now...)
[10:26:25] <Eliot.Lear> ok, let me know if there are othres i should close
[10:26:49] <sftcd> checking 'em now...
[10:28:44] <sftcd> CLOSE 1196 - agreed on 20060518 11:22:20 in the log http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-18.html
[10:28:55] <Eliot.Lear> done
[10:32:38] <sftcd> ACCEPT 1204 - not sure - must ask the example in 3.4 seems to include the change but can't see the text so this is ACCEPTED but maybe not yet done
[10:33:13] <Eliot.Lear> that sounds like a question for today's esteemed group
[10:33:48] <sftcd> yep
[10:34:32] <sftcd> OPEN 1221 - don't think those changes were done to base yet (sender->originator or somesuch)
[10:34:57] <Eliot.Lear> right. it is.
[10:36:35] <sftcd> OPEN 1229 - pretty sure we agreed to close is based on Paul H being liaison but can't see note - let's try CLOSE today if Paul's on the call
[10:36:57] <Eliot.Lear> ok
[10:38:08] <sftcd> CLOSE 1231 - the reference is gone from -03a
[10:38:53] <Eliot.Lear> done.
[10:38:58] <sftcd> CLOSE 1235 - threats text was changed along these lines
[10:39:49] --- dcrocker has joined
[10:39:49] <Eliot.Lear> done
[10:40:00] <Eliot.Lear> good morning, dave.
[10:40:33] --- Barry Leiba has joined
[10:40:38] <sftcd> OPEN 1236 - Eric included changes in -02 and -03a but haven't heard from hector - let's try CLOSE today
[10:40:42] <Eliot.Lear> good morning, barry.
[10:40:49] <Barry Leiba> Hey.
[10:40:59] <sftcd> (Folks - was just going over the open issues with Eliot doing a bit of tidying)
[10:41:03] <Eliot.Lear> open
[10:41:06] <Eliot.Lear> (done)
[10:42:08] <Eliot.Lear> what do you want done with the textual change doug has suggested regarding b=?
[10:42:13] <Eliot.Lear> should i open an issue for that?
[10:42:18] <sftcd> CLOSE 1258 - this was agreed on a jabber and is in -02 & -03a
[10:42:25] * sftcd has set the topic to: DKIM meeting in 20 mins
[10:42:48] <Eliot.Lear> 1258 closed
[10:43:07] <sftcd> wrt b= I don' t get his point but sure - open an issue so we cover it
[10:43:50] <sftcd> CLOSE 1283 - discussed a week ago and -03a has the resolution (use TFAIL etc)
[10:44:08] <Eliot.Lear> ok, this is where my nit comes in.
[10:44:17] <Eliot.Lear> but we can treat it separately
[10:44:45] <sftcd> ok - raise an nitissue for yours I guess
[10:45:18] <sftcd> Think that's all the housekeeping - other issues were raised since last monday
[10:45:22] <Eliot.Lear> yeah, the issue is simple. we're telling people not to throw smtp errors in one place and discussing just how to do so in several places
[10:45:36] <sftcd> (sounds right to me to have one
[10:45:43] <sftcd> place to say whatever)
[10:45:54] <Eliot.Lear> at least that's my logic
[10:47:02] <sftcd> I see 10 isues open - 1201 (SSP), 1204 (probably done), 1217 (SSP), 1221 (terminology), 1229 (liasion), 1236 (check with issue generator) and recent ones - not bad!
[10:47:19] <sftcd> we wont be here two hours so!
[10:47:21] <Eliot.Lear> and one will be added shortly
[10:47:26] <Eliot.Lear> (b=
[10:47:27] <Eliot.Lear> )
[10:47:33] <sftcd> sure
[10:48:05] <sftcd> I'll recap those we just shut down once the meeting starts
[10:48:13] --- fenton has joined
[10:48:51] <fenton> Morning, all; back after a quick breakfast
[10:49:06] --- doug_trendmicro@jabber.org has joined
[10:49:39] <Eliot.Lear> greetings
[10:49:53] <Eliot.Lear> stephen, doug's raised a few other issues today i'm just catching up on.
[10:50:08] <sftcd> Whack them in and we'll get to them
[10:50:15] <Eliot.Lear> ok
[10:50:18] <doug_trendmicro@jabber.org> Is there a diff on the changes made by Eric?
[10:50:48] <sftcd> isnt' there a generic tool for that?
[10:51:21] --- boxley has joined
[10:52:27] <doug_trendmicro@jabber.org> Does it work for html only?
[10:52:44] * Barry Leiba has changed the subject to: DKIM meeting in about 5 mins
[10:52:54] <doug_trendmicro@jabber.org> txt == html?
[10:55:00] <Eliot.Lear> ok, that's two more - 1289 and 1290
[10:55:10] * sftcd has set the topic to: DKIM meeting in exactly 5 mins :-)
[10:55:41] * Barry Leiba has changed the subject to: DKIM meeting in less than 5 mins!
[10:55:56] <Barry Leiba> Pththththth
[10:56:07] <sftcd> Good - so we've 12 open issues, about 7-8 of which need (quick:-) chats..
[10:56:21] <Barry Leiba> "Quick" being the operative word.
[10:56:30] <Eliot.Lear> this could make for a really short wg meeting
[10:56:32] <dcrocker> link to the issues list?
[10:56:34] <sftcd> open issues at 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&Page=1&Format=
[10:56:36] <doug_trendmicro@jabber.org> The security consideration text regarding handling of a _domainkey subdomain in a highlevel domain was reviewed by a DNS expert without an error being noted.
[10:56:40] <dcrocker> tnx
[10:56:53] --- paulehoffman@jabber.org has joined
[10:57:02] <Eliot.Lear> well that's good
[10:57:40] --- thomasm has joined
[10:58:54] * sftcd has set the topic to: DKIM meeting in less than 5 mins!
[10:59:09] * sftcd has set the topic to: DKIM meeting on your marks...
[10:59:20] * sftcd has set the topic to: DKIM meeting get set...
[10:59:41] * sftcd has set the topic to: DKIM meeting go!
[10:59:44] --- sm-msk has joined
[10:59:45] <sftcd> Hi all
[10:59:49] <sftcd> Today's agenda:
[10:59:51] <sm-msk> good morning
[11:00:00] <Barry Leiba> Hey Murray
[11:00:00] <sftcd> Agenda: #1 agenda bashing #2 catch up - issues housekeeping #3 open issues with base #4 getting to WGLC on base #4 AOB
[11:00:11] <sftcd> we're on #1
[11:00:17] * sftcd has set the topic to: DKIM meeting agenda bashing
[11:00:21] <sm-msk> *ahem* stupid agenda!
[11:00:29] --- jrlevine has joined
[11:00:46] <Barry Leiba> OK, now that's done.
[11:00:55] <sftcd> ok so #1
[11:00:58] <sftcd> oops #2
[11:01:21] <sftcd> I went through the open issues with Eliot earlier and closed a bunch
[11:01:31] <sftcd> some remain open though
[11:01:42] <sftcd> its in the log earlier but so you can see 'em:
[11:01:47] <sftcd> CLOSE 1185 - done in base -02 CLOSE 1196 - agreed on 20060518 11:22:20 in the log http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-18.html ACCEPT 1204 - not sure - must ask the example in 3.4 seems to include the change but can't see the text so this is ACCEPTED but maybe not yet done OPEN 1221 - don't think those changes were done to base yet (sender->originator or somesuch) OPEN 1229 - pretty sure we agreed to close is based on Paul H being liaison but can't see note - let's try CLOSE today if Paul's on the call CLOSE 1231 - the reference is gone from -03a CLOSE 1235 - threats text was changed along these lines OPEN 1236 - Eric included changes in -02 and -03a but haven't heard from hector - let's try CLOSE today CLOSE 1258 - this was agreed on a jabber and is in -02 & -03a CLOSE 1283 - discussed a week ago and -03a has the resolution (use TFAIL etc)
[11:01:54] <sftcd> need to take a mo?
[11:02:11] <fenton> I trust you
[11:02:19] <sftcd> ta
[11:02:32] <sftcd> ok, so we're down to 12 issues fow now, some not for base
[11:02:40] <sftcd> (agenda #3)
[11:02:44] <sftcd> let's go through 'em in trun
[11:02:45] <paulehoffman@jabber.org> On 1229: I am purposely waiting until after Montreal on this one. I am not at all convinced EAI is converging.
[11:02:48] <sftcd> issues list is at:
[11:02:55] <sftcd> 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&Page=1&Format=
[11:03:05] <sftcd> everyone ready? (early ones are easy)
[11:03:22] <sftcd> 1201 applies to ssp
[11:03:32] <sftcd> 1204 -
[11:03:45] <sftcd> I believe this is fixed but can someone else confirm since I never fully got it
[11:03:58] <Eliot.Lear> there was some discussion of 1201 but i wanted to be clear
[11:04:03] <Eliot.Lear> this is an implementation concern, right?
[11:04:09] <thomasm> eric sez he's going to fix it, but I thought we agreed to close it?
[11:04:17] <Eliot.Lear> i wanted to confirm that.
[11:04:29] <thomasm> yes, it's an implementation issue
[11:04:41] <Eliot.Lear> can it be closed then?
[11:04:45] <fenton> I'm confused
[11:04:45] <doug_trendmicro@jabber.org> Is this about base?
[11:04:47] <thomasm> yes
[11:04:49] <sftcd> so we should leave 1204 open pending the fix to the text or close it since there's no change needed?
[11:05:00] <thomasm> ?
[11:05:06] <Eliot.Lear> i'm talking about 1201
[11:05:08] <Eliot.Lear> (still)
[11:05:13] <sftcd> ah reset then - back to 1201
[11:05:39] <Eliot.Lear> this is a milter bug, right?
[11:05:48] <thomasm> 1201 is part of larger discussion -- for later
[11:05:59] --- tonyhansen has joined
[11:06:00] <thomasm> 1204 is the milter bug
[11:06:14] <Eliot.Lear> so it is, i'm sorry.
[11:06:18] <Eliot.Lear> yes, 1204.
[11:06:20] <sm-msk> uh oh
[11:06:20] <Eliot.Lear> sorry
[11:06:29] <sm-msk> URL or something for 1204?
[11:06:34] <sftcd> ok - so 1201 is just ssp and nothting else?
[11:06:36] <fenton> aargh! what issue are we on?
[11:06:39] <Eliot.Lear> https://rt.psg.com/Ticket/Display.html?id=1204
[11:06:42] <sftcd> (murray - follow issues link)
[11:06:58] <sm-msk> going
[11:07:08] <sftcd> Eliot - you have nothing on 1201 right?
[11:07:16] <jrlevine> rt.psg.com is asking me for a password, can someone tell me what to use?
[11:07:20] <Eliot.Lear> right
[11:07:20] <sm-msk> same
[11:07:23] <fenton> ietf/ietf
[11:07:48] <sftcd> so now we're on 1204
[11:07:52] <sftcd> which is the milter one
[11:08:06] <Eliot.Lear> right. this is an implementation issue, right?
[11:08:06] <sftcd> is there a change needed for base or do we close this?
[11:08:15] <thomasm> murray -- 1204 is pretty well known -- we can take it offline if you like
[11:08:22] <thomasm> close it, IMO
[11:08:29] <sftcd> tony - you raised it?
[11:08:29] <sm-msk> no, i'm caught up now, i thought this was a new problem
[11:08:36] <thomasm> nope
[11:08:48] <sm-msk> i agree, close it. in fact there are other things the MTA does not listed here which mess with simple.
[11:08:54] <sftcd> so CLOSE 1204 then - any objection?
[11:08:56] <sm-msk> (it's the MTA, not milter)
[11:09:10] <sftcd> none.
[11:09:22] <sftcd> next issue 1217 is ssp again - so nothing for now
[11:09:30] <sftcd> skipping on to 1221
[11:09:31] <thomasm> isn't this a dupe of 1201?
[11:09:37] <sftcd> I don't care (now)
[11:09:56] <sftcd> 1221 - dave this was your sender/originator terminology one - does base also need changes?
[11:10:46] <sftcd> seems like not?
[11:11:01] <dcrocker> sorry. i need more reminder. i remember raising the issue but not why the issue is still open or whether i had an action.
[11:11:09] <sftcd> fair enough
[11:11:25] <sftcd> Jim made changes to threats for this, question is whether same is needed in base
[11:11:36] <sftcd> Jim do you recall the changes you made?
[11:11:39] <doug_trendmicro@jabber.org> This should also include a definition for signing address as well i.e. i= identity.
[11:12:10] <fenton> I don't remember having done anything in an organized way on this for -threats
[11:12:11] <boxley> no it shouldnt
[11:12:27] <boxley> this is to identify the mta vs the author of a message
[11:12:37] <jrlevine> As I recall, some ambiguity between sender and signer in the doc?
[11:12:59] <sftcd> maybe best to close and action Dave to raise a new issues if necessary?
[11:13:18] <boxley> author - orginator-operator-operator-receiptient
[11:13:22] <thomasm> yeah -- 3 months old -- it's a little stale
[11:13:23] <doug_trendmicro@jabber.org> I have also already posted the comment about signing address...
[11:13:40] <fenton> I wonder if Dave can propose specific places the language needs to be changed -- there aren't that many occurrences of 'sender'
[11:14:39] <dcrocker> just did a scan. sender gets used variously and sometimes i'm not even sure what is specifically meant. i think that, yes, that means I should post a case analysis with suggestions. will do that today.
[11:14:52] <doug_trendmicro@jabber.org> Both sender and signing...
[11:15:10] <fenton> thanks. I see places where 'sender' needs to stay because it means the sender header field
[11:15:14] <sftcd> CLOSE 1221 - dave to raise new issue bsed on current -03a text
[11:15:30] <doug_trendmicro@jabber.org> 03b you mean?
[11:15:36] <sftcd> yes, sorry
[11:15:51] <sftcd> 1229 - z= & EAI which is Paul's Liasion thingy
[11:16:06] <sftcd> Suggest we get whatever news Paul has to offer and close the issue too
[11:16:49] <sftcd> Any news Paul?
[11:16:52] <paulehoffman@jabber.org> As I said above, I want to wait until after Montreal.
[11:17:01] <sftcd> so ok if we close this until then?
[11:17:03] <paulehoffman@jabber.org> Feel free to close it.
[11:17:15] <sftcd> CLOSE 1229 - PH to re-raise after Montreal as necessary
[11:17:18] <paulehoffman@jabber.org> If I have something definite, I'll propose it as a wording change.
[11:17:40] <sftcd> 1236 - failure cases as raised by Hector
[11:17:57] <thomasm> this is accommodated by this draft, right?
[11:18:00] <sftcd> I think that Eric did this, but want to check here
[11:18:10] <Barry Leiba> Hector's been quiet.
[11:18:24] <jrlevine> We decided that all failure is the same, the cause is a comment
[11:18:26] <sftcd> (there was a subsequent issue from Jim that we closed already - never hit this one though)
[11:18:37] <doug_trendmicro@jabber.org> This seem to be more of an implementation concern.
[11:18:48] <sftcd> so we're closing this barring objections...
[11:19:11] <sftcd> CLOSE 1236 - taken into account already in -02 (forgot to close before)
[11:19:27] <sftcd> That's all the ancient ones done
[11:19:38] <sftcd> now 1285 - Doug's security considerations
[11:19:57] <doug_trendmicro@jabber.org> I have refreshed this section
[11:20:15] <thomasm> sure doesn't seem like there's any groundswell for a change to me
[11:20:21] <fenton> This goes to a bigger issue of whether we need to repeat everything in -threats
[11:20:38] <sftcd> answer to that is no
[11:20:39] <Eliot.Lear> i would think a reference is sufficient.
[11:20:44] <doug_trendmicro@jabber.org> The threats document did not cover this issue properly.
[11:20:46] <thomasm> #include "dkim-threats"
[11:20:50] <Barry Leiba> Repeat: no, surely not. Refer to -threats.
[11:20:58] <tonyhansen> I see no problem with adding the note for 1285, though
[11:21:08] <paulehoffman@jabber.org> It also goes to whether or not we have security considerations for things that few people (or one person) find a threat.
[11:21:31] <Eliot.Lear> tony, what would the note say?
[11:21:36] <doug_trendmicro@jabber.org> Is it a threat none the less?
[11:21:43] <fenton> There is already a reference to -threats at the beginning of Security Considerations
[11:21:53] <paulehoffman@jabber.org> Doug: no.
[11:22:11] <doug_trendmicro@jabber.org> The threat draft misses the concerns completely. For example the g= issue.
[11:22:15] <Eliot.Lear> i'm also not sure what text we're arguing over, if you say you have new text, doug.
[11:22:29] <Barry Leiba> We've had lots of discussion on the list on this. ...
[11:22:35] <doug_trendmicro@jabber.org> It was posted to the list.
[11:22:36] <thomasm> the threats draft had wg consesus
[11:22:37] <Barry Leiba> Doug thinks it's a significant threat. ...
[11:22:41] <Barry Leiba> No one else does. ...
[11:22:48] <boxley> noting that tld's can overide dkim settings on leafs should perhaps be noted
[11:22:52] <Barry Leiba> Is it reasonable to document it in "security considerations"?
[11:23:08] <tonyhansen> 1285 says to doc in security considerations
[11:23:16] <jrlevine> only if we're planning to reiterate every other DNS concern in the world
[11:23:18] <paulehoffman@jabber.org> Brian: that isn't true.
[11:23:31] <thomasm> if we do, my suggestion is to just take what we have consensus on -- which is in -threats
[11:23:39] <doug_trendmicro@jabber.org> Only as related to the _domainkey concern?
[11:24:10] <doug_trendmicro@jabber.org> This has a significant impact on the possible security issues and modifications to contracts that now need to list these issuse.
[11:24:15] <paulehoffman@jabber.org> Brian: TLDs cannot override dkim settings because the dkim settings are in the signed headers.
[11:24:30] <thomasm> But referring to -threats in security considerations seems plenty of warning
[11:24:38] <tonyhansen> actually, the text in 1285 has two parts, one buried in the proposed security considerations text. One is a requirement to disallow _ in i= parameters. The reason is what's in the proposed s.c. text.
[11:24:54] <doug_trendmicro@jabber.org> No. The issue is about validating an email address by a higher level domain effectively.
[11:25:06] <jrlevine> parents can control what keys are ino the DNS and what can be validated. That's life.
[11:25:11] <boxley> actually its bill, and if I own the domains I can change keys for leafs,
[11:25:25] <jrlevine> I see N-1 of us happy with current wording
[11:25:26] <doug_trendmicro@jabber.org> A higher level domain may issue MUA keys and this all bets are off on what happens at a lower subdomain.
[11:25:38] <paulehoffman@jabber.org> s/Brian/Bill (plus apologies)
[11:25:59] <fenton> Bill: isn't what's in 4.1.18 of -threats sufficient?
[11:26:14] <boxley> its fine
[11:26:28] <doug_trendmicro@jabber.org> No. It implies no added agreements are needed.
[11:26:33] <paulehoffman@jabber.org> Bill: That's not what this issue is about. It is about them putting their own _domainkey records at a higher level and messages having a d= pointing to the higher level.
[11:26:43] <Barry Leiba> I see consensus not to change this. Yet I'm worried that we're missing something. ...
[11:26:59] <Barry Leiba> We could leave it for the IESG to consider.
[11:27:10] <Eliot.Lear> yes, that helps get a document through... not
[11:27:16] <Eliot.Lear> ;-)
[11:27:40] <paulehoffman@jabber.org> Doug can write a document on this as an individual submission.
[11:27:42] <Barry Leiba> Then putting something in SC might be the right answer.
[11:27:51] <sftcd> if we were to accept this, woulud the current wording be ok? and if not, who'd take an action to work with Doug to wordsmith?
[11:27:51] <doug_trendmicro@jabber.org> Okay.
[11:27:54] <jrlevine> Technical reality: parent controls subdomain Political reality: domain registries s*ck but we're technical here
[11:27:54] <Eliot.Lear> doug how is this concern any different from any other use of DNS?
[11:28:27] <paulehoffman@jabber.org> Barry, I will restate what I said above: if few or one person thinks it is a threat, it doesn't belong in a WG consensus document.
[11:28:38] <Barry Leiba> Paul: I understand.
[11:28:47] <Eliot.Lear> if we're not going to use X.509, I don't see how we avoid the underlying problem of a switcheroo
[11:28:54] <doug_trendmicro@jabber.org> The issue is related not to delegation but the use of a _domainkey subdomain at a higher level. This is a different issue unrelated to current agreements.
[11:28:54] <fenton> There are lots of 'security considerations' that are described in -threats that aren't in section 8 of -base. Why is this one special?
[11:28:57] <tonyhansen> rereading threats ss 4.1.18 and 1285, it looks like 4.1.18 covers this issue as a concern. However, the suggestion to disallow _ in i= might still be considered as a way of addressing some of 4.1.18's concerns.
[11:28:59] <Barry Leiba> That's why I said we could let the IESG consider it and decide whether to bounce it back.
[11:29:10] <paulehoffman@jabber.org> Eliot: see my response on the list to Doug's earlier posting.
[11:29:18] <Barry Leiba> (IOW, Doug would re-raise this in Last Call.)
[11:29:38] <sftcd> So we have just one voice for the change?
[11:29:49] <sftcd> in which case consensus is clear, right?
[11:29:52] <fenton> 4.1.18 doesn't deal with _ in i= at all
[11:30:13] <tonyhansen> no, 4.1.18 doesn't specifically mention _ in i=.
[11:30:16] <sftcd> (jim, tony - wouldn't that be a separate issue to sec cons.)
[11:30:30] <Eliot.Lear> tony, looks to me like i= text might be reasonable.
[11:30:37] <fenton> _ in i= sounds like it might be a separate concern, yes.
[11:30:43] <fenton> need to think about that more.
[11:30:52] <thomasm> what is _in?
[11:31:03] <tonyhansen> "_" found in i= parameter
[11:31:16] <fenton> I left off quotes: Underscore characters in i=
[11:31:22] <sftcd> I'm going to suggest we CLOSE 1285...objections? (I assume Doug objects)
[11:31:29] <boxley> no
[11:31:29] <thomasm> that sure sounds like a different issue
[11:31:35] <paulehoffman@jabber.org> Why would someone signing a message every put _ in a host name in i=?
[11:31:43] <doug_trendmicro@jabber.org> Yes, objection should be noted.
[11:31:47] <sftcd> so noted
[11:31:48] <fenton> Mike: It is, I'm not convinced it will be a problem but need to think more.
[11:32:03] <sftcd> and raise a new issue if it is a problem or worthwhile addition
[11:32:11] <sftcd> menwhile 1285...going..
[11:32:12] <tonyhansen> like I said, 1285 has two parts. We're happy with closing part of it. Still a question on "_" in i=, though.
[11:32:20] <fenton> Paul: Good question. I don't think it will turn out to be a problem.
[11:32:31] <sftcd> yes, but raise a new issue if necessary
[11:32:34] <sftcd> gone
[11:33:02] <jrlevine> If you want, I can file 190 other questions about the other non alnum characters, too. I don't see any point
[11:33:08] <sftcd> CLOSE 1285 - no support but Doug asked his objection be noted, possible new issue about "_" in i= to be raised if necessary
[11:33:33] <sftcd> next is 1286 - alg abnf
[11:33:50] <paulehoffman@jabber.org> +1 on 1286
[11:34:09] <tonyhansen> +1
[11:35:11] <sm-msk> +1
[11:35:19] <Barry Leiba> Are we set on 1286, then?
[11:35:22] <doug_trendmicro@jabber.org> You should note a small change however. The algorithm label for hash must now lead with alpha.
[11:35:31] <sftcd> 1286, yes
[11:35:37] <fenton> I have a related question
[11:35:48] <sftcd> can someone give me an example of the old & new values?
[11:35:56] <sftcd> (I have a potential issue, depending)
[11:36:07] <sftcd> but first, jim...
[11:36:32] <fenton> We have two tags for alg and hash in the key record, but one in the signature, do I have that right?
[11:36:42] <paulehoffman@jabber.org> Jim: yep
[11:36:58] <fenton> I'm wondering why we're inconsistent on this.
[11:37:02] <doug_trendmicro@jabber.org> The key record creates lists for hash and algorithm separately.
[11:37:15] <thomasm> yeah, it's the lists jim
[11:37:29] <fenton> huh?
[11:37:32] <doug_trendmicro@jabber.org> This new definition makes it clear what goes where.
[11:37:38] <thomasm> sha256:sha1 etc
[11:37:43] <thomasm> you can't do that for the sig
[11:37:53] <thomasm> so it makes some sense to combine them in the sig
[11:38:16] <fenton> oh yeah. That answers it, thanks.
[11:38:32] <sftcd> so me now - examples please?
[11:38:57] <paulehoffman@jabber.org> Stephen: if we have a new hash algorithm
[11:39:24] <doug_trendmicro@jabber.org> It could be rsa-sf512
[11:39:34] <paulehoffman@jabber.org> Doug's change makes it explicit which part of the string is the hash algorithm and which part is the signing algorithm.
[11:39:43] <sftcd> let me try then. old "rsa-sha256" new "rsa/sha256" is that it?
[11:39:54] <doug_trendmicro@jabber.org> The older definition would have allowed ras-512
[11:40:06] <sftcd> was I right or wrong above?
[11:40:10] <paulehoffman@jabber.org> Wrong
[11:40:13] <Eliot.Lear> where is the slash in the ABNF?
[11:40:13] <thomasm> I hope you're wrong
[11:40:15] <paulehoffman@jabber.org> There is no slash there.
[11:40:23] <doug_trendmicro@jabber.org> No you must use a '-'
[11:40:49] <sftcd> ok so your change is just to make the "-" a separator rather than a value?
[11:40:56] <thomasm> I don't see the reason to disallow a leading number for the algo -- why not rsa-23skeedo
[11:40:56] <paulehoffman@jabber.org> Yep
[11:41:03] <doug_trendmicro@jabber.org> Yes
[11:41:04] <sftcd> I dislike it!
[11:41:15] <doug_trendmicro@jabber.org> why?
[11:41:23] <sftcd> reason: makes it easier to introduce encumbered crypto
[11:41:33] <thomasm> ??
[11:41:34] <Eliot.Lear> it's a nit but i think the "/" conveys better separation. not something i'd stand on my head tho
[11:41:45] <boxley> ? encumbered crypto
[11:41:46] <sftcd> TLS rejected 48 new ciphersuites but would have accepted 1 new alg id
[11:41:49] <paulehoffman@jabber.org> Stephen: no way. It's just as easy now.
[11:42:02] <thomasm> let's not be making cosmetic changes that affect back compatability...
[11:42:05] <sftcd> that's what happened with ECC
[11:42:17] <Eliot.Lear> mat: good point
[11:42:27] <paulehoffman@jabber.org> We have x-sig-a-tag-alg already.
[11:42:37] <Eliot.Lear> rihgt
[11:43:15] <fenton> If someone wants to sign with an encumbered alg, they're welcome to, but it might not get verified by everybody :-)
[11:43:27] <sftcd> fair enough, I'd be a "-1" here, but I see lots of +'s, right?
[11:43:41] <fenton> +
[11:43:46] <Eliot.Lear> +1
[11:43:51] <paulehoffman@jabber.org> Stephen: you would have to put a -1 on the current text as well.
[11:44:01] <doug_trendmicro@jabber.org> +1
[11:44:07] <boxley> -no opinion
[11:44:21] <sftcd> ACCEPT 1286 - almost all people like it except for one crank:-)
[11:44:34] <sftcd> 1287 - signature removal
[11:44:52] <sftcd> (timing issue - are folks ok to go beyone 1600 UTC?)
[11:44:59] <thomasm> first, haven't we been through this endlessly?
[11:45:00] <doug_trendmicro@jabber.org> Why make this a SHOULD even?
[11:45:10] <thomasm> I have to run at the top of the hour
[11:45:17] <fenton> (I'm OK to 1630Z)
[11:45:18] <doug_trendmicro@jabber.org> Not that I recall?
[11:45:31] <jrlevine> I have to agree with Doug, no point to leaving a known broken sig
[11:45:42] <thomasm> forensics
[11:45:55] <paulehoffman@jabber.org> Disagree: just because it is broken for you doesn't mean it will be broken for someone later.
[11:45:56] <jrlevine> I suppose
[11:45:57] <sftcd> (murray has an AOB that we'll switch to at 1555Z, then press on if there're enough of us left)
[11:46:12] <Eliot.Lear> consider the case of the use of a proprietary signing algorithm ;-)
[11:46:19] <sftcd> yuk
[11:46:25] <fenton> Paul +1
[11:46:36] <paulehoffman@jabber.org> -1 on this. There are cases where an attacker can cause a signature to be broken at one point but not in the future by DNS cache poisoning.
[11:46:44] <jrlevine> I thought it meant broken like you're a mailing list and you stripped a MIME part
[11:46:55] <dcrocker> I think the larger issue is whether an intermediary should be messing with message content, beyond specific actions that are inherently required, such as ADDING a signature.
[11:47:05] <jrlevine> that's what "know that the signatures | cannot be verified." says to me
[11:47:13] <jrlevine> I agree leave it in if you don't know
[11:47:15] <sftcd> any voices for this other than Doug?
[11:47:26] <paulehoffman@jabber.org> John: there are many reasons why one processor could not verify a signature.
[11:47:30] <thomasm> -1 on 1287
[11:47:38] <jrlevine> tarpit ahead: is a mailing list an intermediary?
[11:47:44] <doug_trendmicro@jabber.org> There may be a case where signatures should be stripped. The SHOULD NOT makes this recommendation more difficult to get accepted when needed.
[11:48:03] <dcrocker> john "know that sigs cannot be verified" is probably ambiguous to result in wildly different interpretations.
[11:48:06] <doug_trendmicro@jabber.org> The size of messages could also grow to being mostly headers.
[11:48:12] <paulehoffman@jabber.org> "SHOULD NOT" has very specific semantics.
[11:48:19] <doug_trendmicro@jabber.org> The DKIM Signature is not that small.
[11:48:21] <jrlevine> Again "could not verify" != "know that it cannot be verified"
[11:48:22] <paulehoffman@jabber.org> Size: so what?
[11:48:36] <dcrocker> intermediary -> relay (MTA and the like, not MUA-level re-submitters.)
[11:48:56] <Eliot.Lear> Doug, what's the DoS?
[11:49:09] <jrlevine> My suggestion: remove if it is definitely broken, don't remove otherwise
[11:49:14] <jrlevine> I think that's what Doug's suggesting
[11:49:23] <sftcd> so you support this one?
[11:49:24] <doug_trendmicro@jabber.org> Yes.
[11:49:27] <jrlevine> DoS is a hundred bogus sigs to swamp the verifier
[11:49:30] <sftcd> I meant John
[11:49:44] <jrlevine> admittedly, that's only tangential here
[11:49:44] <thomasm> verifiers can easily detect something like that
[11:49:47] <boxley> I support removing the SHOULD NOT
[11:49:56] <sftcd> SOULD NOT would IMO allow removal of the 1st 1000 sigs -
[11:50:02] <fenton> The DoS exists whether or not you strip sigs
[11:50:20] <thomasm> right
[11:50:35] <jrlevine> I guess I support rewording it to say more clearly what I think it means
[11:50:40] <Eliot.Lear> is the concern an intermediary or what/
[11:50:40] <jrlevine> clearly we're reading it differently
[11:50:42] <Eliot.Lear> ?
[11:50:45] <boxley> If I am relaying I might not want to sign at all, If I am the originator there should not be any prior sigs
[11:51:05] <Eliot.Lear> if you're the originator there's nothing to strip ;-)
[11:51:06] <boxley> it seems to apply to mailing lists
[11:51:09] <paulehoffman@jabber.org> John: suggest working to the mailing list.
[11:51:14] <jrlevine> OK, will do
[11:51:28] <sftcd> so let's leave this open pending John's action...ok?
[11:51:33] <doug_trendmicro@jabber.org> That sounds good.
[11:51:47] <sftcd> next - murray what's your AOB item?
[11:52:25] <sftcd> (then there're only 3 more current issues so we should try finish them)
[11:53:08] <sftcd> he seems to be having coffee so let's try 1288, signing address
[11:53:12] <boxley> need to leave, will read log later
[11:53:15] --- boxley has left
[11:53:42] <doug_trendmicro@jabber.org> There is no current definition for this term.
[11:53:42] <paulehoffman@jabber.org> +1 on 1288 if we replace "*@<d=domain>" with "address".
[11:54:01] <doug_trendmicro@jabber.org> What is meant by address?
[11:54:16] <paulehoffman@jabber.org> "default address" is defined earlier, yes?
[11:54:39] <doug_trendmicro@jabber.org> for i=?
[11:54:57] <paulehoffman@jabber.org> Whoops, no it isn't. Never mind.
[11:55:25] <doug_trendmicro@jabber.org> This term is used in several places without being defined.
[11:55:27] <jrlevine> it's in the i= part of 3.5
[11:55:30] <tonyhansen> how about its default address (*@<d=domain>) when ...
[11:55:39] <paulehoffman@jabber.org> +1 on 1288 as is.
[11:55:43] <fenton> Doug: Are you proposing to delete the first paragraph, or only change the second one?
[11:55:50] <paulehoffman@jabber.org> ... or Tony's rewrite.
[11:55:55] <doug_trendmicro@jabber.org> change
[11:56:17] <doug_trendmicro@jabber.org> Only the informative section.
[11:56:32] <fenton> I don't agree with what it says the default is
[11:56:41] <sftcd> is it ok to specify the default in an INFORMATIVE bit?
[11:57:02] <tonyhansen> this who text is in an INFORMATIVE bit
[11:57:03] <doug_trendmicro@jabber.org> Well this was the first instance of the term.
[11:57:10] <tonyhansen> this whole ...
[11:57:14] <paulehoffman@jabber.org> Jim: good catch. There is no "*" in the definition for i=.
[11:57:16] <fenton> The default is that the user name is unknown or unspecified, not '*' which might mean "everyone"
[11:57:54] <doug_trendmicro@jabber.org> I would be happy to see this definition moved ahead of this point and corrected to make Jim happy.
[11:58:00] <fenton> I would just say "its default value as specified in [some section]"
[11:58:11] <thomasm> +1 to Jim
[11:58:15] <sm-msk> or "anyone"
[11:58:25] <fenton> right
[11:58:30] <sftcd> who's taking an action to propose the specific fix?
[11:58:37] <doug_trendmicro@jabber.org> The default as defined by i= parameter?
[11:58:45] <fenton> I'll take the action
[11:59:00] <sftcd> great. so we leave 1288 OPEN pending that
[11:59:13] <sftcd> murray's back now...so murray your AOB?
[11:59:32] <sm-msk> just a question about that signature id change i proposed but withdrew last week
[11:59:36] <Barry Leiba> I'm getting on a conference call now. I'll still be here, but not paying full attention.
[11:59:48] <sm-msk> should i be making that into an individual draft, or would this be a draft that the WG takes up after -base goes out for real?
[12:00:18] <sftcd> for now certainly anything should be an individual draft (could be incorporated into your other one if you like)
[12:00:25] <doug_trendmicro@jabber.org> A recommendation about how much of a signature to use?
[12:00:44] <sm-msk> doug: more importantly, naming the tag that will contain the identifier, but yes that too
[12:01:13] <doug_trendmicro@jabber.org> The b= and then N number of bytes?
[12:01:27] <sftcd> does that answer your question murray? (let;s not get into detail about it now)
[12:01:37] <sm-msk> yeah it's just a procedural question
[12:01:38] <Eliot.Lear> ciao
[12:01:42] --- Eliot.Lear has left
[12:01:44] <thomasm> murray -- you should just do a hash of the signature
[12:01:45] <sm-msk> is it a good idea to roll it into auth-results?
[12:01:52] <sm-msk> or do it separately
[12:01:58] <sftcd> we've two more open issues, so let's try get them done now
[12:02:00] <thomasm> into auth-res, Murray
[12:02:03] <sm-msk> i'd prefer separately
[12:02:16] <sftcd> issues 1289 - some clarification ...
[12:02:38] <paulehoffman@jabber.org> -1 on 1289 without specific wording.
[12:02:42] <doug_trendmicro@jabber.org> I have posted the wording asked by Stephen to the list.
[12:03:13] <tonyhansen> yes, specific wording changes were posted this am.
[12:03:17] <Barry Leiba> I agree with Doug that it's a good idea to make this clear.
[12:03:20] <sftcd> arvhice URL doug ?
[12:03:39] <tonyhansen> have some quibbles on the specific text, but overall support the change
[12:03:44] <doug_trendmicro@jabber.org> I am looking...
[12:04:16] <sftcd> thanks - it'll help Eric if we accept
[12:04:23] <fenton> Tony +1
[12:04:23] <thomasm> maybe just leave the jist of the clarification to Eric
[12:04:39] <sftcd> I'm ok with that once he has the pointer
[12:04:48] <jrlevine> agree to punt to Eric, we all seem to agree what it should tell people
[12:05:33] <doug_trendmicro@jabber.org> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003830.html
[12:05:37] <doug_trendmicro@jabber.org> Too late.
[12:05:59] <paulehoffman@jabber.org> I see it now. Agree that it probably says the right thing, but let Eric nit-pick on it.
[12:06:10] <tonyhansen> no, not too late, now the pointer is in the log :-)
[12:06:20] <sftcd> that's the wrong URL above
[12:06:29] <sftcd> I think you wanted http://mipassoc.org/pipermail/ietf-dkim/2006q2/003834.html
[12:06:33] <doug_trendmicro@jabber.org> Damn
[12:07:04] <sftcd> ACCEPT 1289 - modulo editor (Eric) wordsmithing - closest approach is http://mipassoc.org/pipermail/ietf-dkim/2006q2/003834.html
[12:07:17] <sftcd> Last one for now then: 1290
[12:07:31] <sftcd> the yellow book about falling off camels and stuff...
[12:07:40] <nealmcb> [For the record, this is Neal McBurnett, neal@bcn.boulder.co.us, just lurking]
[12:07:50] <sftcd> Hi Neal
[12:07:56] <nealmcb> howdy
[12:08:05] <paulehoffman@jabber.org> -1 on 1290 for the same reasons we had earlier, plus now the alternate root quagmire.
[12:08:14] <sftcd> so 1290 - worst case scenario
[12:08:20] <tonyhansen> hi Neal!
[12:08:22] <thomasm> I'm having deja vu all over again
[12:08:38] <sftcd> anyone else for 1290?
[12:08:52] <doug_trendmicro@jabber.org> This seem to have the wrong link?
[12:09:12] <sftcd> what "this"?
[12:09:15] <doug_trendmicro@jabber.org> This is not what was posted?
[12:09:25] <doug_trendmicro@jabber.org> The 1290 issue.
[12:09:58] <fenton> Yeah, the title doesn't match the text
[12:10:05] <paulehoffman@jabber.org> We're 10 minutes over; can we just put this off for a week?
[12:10:36] <sftcd> well let's deal with the "worst case scenario|" and asl Eliot to fix the list
[12:10:42] <fenton> This is new enough that I haven't digested it yet
[12:10:46] <sftcd> (Paul - no chairs around next week)
[12:11:10] <sftcd> so do we want to leave this OPEN 'till next time?
[12:11:19] <sm-msk> next session is 6/22?
[12:11:22] <paulehoffman@jabber.org> Yes
[12:11:26] <fenton> Maybe just resolve on the list
[12:11:30] <sftcd> yes to murray
[12:11:32] <thomasm> +1 jim
[12:11:37] <tonyhansen> *hopefully* resolve on the list
[12:11:37] <doug_trendmicro@jabber.org> That was the link I posted by mistake.
[12:11:39] <sftcd> ok - OPEN for now then.
[12:11:57] <sftcd> so we're on agenda #4 - how to get to WGLC
[12:12:07] <sftcd> we've a two week jabber hiatus
[12:12:26] --- paulehoffman@jabber.org has left: Logged out
[12:12:32] <sftcd> suggest we all try generate all our issues in that time (i.e. we close for new issues on mid-summer's day)
[12:13:00] <fenton> Is that the day before a midsummer nights dream?
[12:13:05] <sftcd> then kill those issues and formally start WGLC whenever the appropriate I-D exists
[12:13:13] <sftcd> Jim - have to ask Eric about that then:-)
[12:13:19] <thomasm> sounds good... gotta go...
[12:13:42] <sftcd> ok so I'll send a mali to the list wrt the plan and we'll see how we go
[12:13:44] --- thomasm has left
[12:13:54] <sm-msk> good work folks
[12:13:56] <sm-msk> talk to you in two weeks
[12:14:04] <sftcd> bye all
[12:14:09] --- sm-msk has left
[12:14:12] <fenton> Stephen: one question
[12:14:15] <sftcd> Sure
[12:14:31] <fenton> We've had all these jabber chats and still I don't know what AOB means!
[12:14:39] <sftcd> any other biz
[12:14:42] <tonyhansen> "any other business"
[12:14:46] <fenton> ah!
[12:14:51] <fenton> thanks!
[12:14:53] <sftcd> ah-ha even!
[12:15:18] <fenton> Since it was always at the end of the agenda, I thought the B stood for Beer
[12:15:23] <fenton> :-)
[12:15:30] <sftcd> so bye for now folks see ya on the list (too early for beer, even here)
[12:15:45] <fenton> bye...
[12:15:48] <doug_trendmicro@jabber.org> Bye
[12:15:56] --- doug_trendmicro@jabber.org has left
[12:15:59] <tonyhansen> bye
[12:16:03] --- sftcd has left
[12:16:32] --- Barry Leiba has left
[12:17:29] --- fenton has left
[12:17:36] --- tonyhansen has left
[12:37:37] --- jrlevine has left
[12:38:22] --- sm-msk has joined
[12:38:57] --- sm-msk has left
[12:50:09] --- paulehoffman@jabber.org has joined
[12:50:38] <paulehoffman@jabber.org> OK, Neal. So why do you care about DKIM? :-)
[13:18:12] --- paulehoffman@jabber.org has left
[14:05:01] --- doug_trendmicro@jabber.org has joined
[14:05:17] --- doug_trendmicro@jabber.org has left
[23:56:13] --- dcrocker has left: Replaced by new connection
[23:56:14] --- dcrocker has joined