[00:45:49] --- jrlevine has joined
[01:19:59] --- dcrocker has left: Replaced by new connection
[01:19:59] --- dcrocker has joined
[01:19:59] --- dcrocker has left
[02:34:57] --- dcrocker has joined
[03:17:43] --- sftcd has joined
[03:18:07] <sftcd> I guess no one else's watching their screen right now?
[03:18:07] --- Paul Hoffman has left: Lost connection
[03:18:31] <sftcd> Ah well.
[03:20:51] <sftcd> I'll check back later a few times before the meeting slot to see if we're still up.
[03:21:49] <sftcd> Meeting is intended to be for 1500 UTC, 1600 Dublin, 1100 New York, 0800 San Francisco
[03:21:58] <sftcd> We'll see if experiment #2 works!
[03:22:00] <sftcd> later.
[03:22:08] --- sftcd has left
[04:20:18] --- dcrocker has left: Replaced by new connection
[04:20:19] --- dcrocker has joined
[09:22:21] --- jpope has joined
[09:23:20] <jpope> Hi ... John Pope joined to check room/server status ... looks like all is well.
[09:24:49] --- jpope has left
[10:03:48] --- mike thomas has joined
[10:08:46] --- eric has joined
[10:08:52] --- fenton has joined
[10:09:08] <eric> g'morning folks. is the room working today?
[10:09:18] <fenton> 'morning, all. looks like it's working.
[10:09:20] <dcrocker> yup
[10:09:30] <eric> excellent. well, time for some breakfast then.
[10:09:53] <mike thomas> I just frothed my breakfast
[10:10:18] <fenton> i'm guessing that involves espresso
[10:10:35] <mike thomas> oui
[10:11:03] --- fenton has left
[10:22:05] --- sftcd has joined
[10:22:33] <sftcd> Hi all - no problems connecting today I hope? (This is Stephen btw)
[10:24:13] * sftcd has set the topic to: Meeting starts in about 30 minutes
[10:24:45] <mike thomas> nope, no probs
[10:25:55] <sftcd> Good, must go knock up an agenda so...
[10:26:13] <sftcd> basically the open issues from Eric's list in that order I 'spose
[10:29:45] <jrlevine> OK, might want to put the issues list on a web server somewhere and publish the URL for people who delete their mail too fast
[10:35:29] <sftcd> It's already available via the archive.
[10:35:35] <sftcd> as is today's agenda... http://mipassoc.org/pipermail/ietf-dkim/2006q2/003648.html
[10:35:52] <sftcd> Eric's list linked from there too
[10:38:06] --- boxley has joined
[10:39:57] * sftcd has set the topic to: Meeting starts in about 20 minutes
[10:45:57] --- Dennis Dayman has joined
[10:46:21] <Dennis Dayman> hello
[10:46:29] --- Peter Koch has joined
[10:47:03] <sftcd> hi dennis
[10:49:09] <Dennis Dayman> you in Ireland?
[10:49:16] <sftcd> yep, and you?
[10:49:19] <Dennis Dayman> might be in Dublin before MAAWG
[10:49:31] <Dennis Dayman> in San Francisco this week, head back to Dallas tomorrow
[10:49:37] <sftcd> when's maawg & where
[10:50:03] <Dennis Dayman> Brussels, Belgium June 27 - 29, 2006
[10:50:47] <sftcd> feel free to drop me a mail if you do make it here
[10:51:00] * sftcd has set the topic to: Meeting starts in about 10 minutes (this is where it went wrong last time:-)
[10:51:19] <Dennis Dayman> will do
[10:53:20] <sftcd> Barry won't be joining us today unfortunately, he had a can't miss thing to do.
[10:54:45] <Dennis Dayman> ehhh, whatever it was he will blog it later ;)
[10:57:08] --- Paul Hoffman has joined
[10:57:20] <sftcd> sound check: I see Bill, Dave, Dennis, Eric, John L, Mike T, Peter K, Paul H. and me.
[10:57:31] <mike thomas> yep
[10:58:04] <mike thomas> jim's probably not going to be able to make it today
[10:58:10] --- doug_trendmicro@jabber.org has joined
[10:58:16] <sftcd> Hi Doug
[10:59:25] * sftcd has set the topic to: Meeting starting
[10:59:31] <sftcd> 1. Agenda bashing (1 minute) 2. Review the open issues listed in Eric's email [1] (40-50 minutes) 3. AOB (5 minutes)
[10:59:46] <sftcd> Anyone got any changes/additions to the agenda?
[11:00:04] * sftcd has set the topic to: Agenda bashing
[11:00:15] <sftcd> Eric's list is at: http://mipassoc.org/pipermail/ietf-dkim/2006q2/003640.html
[11:00:25] <sftcd> No changes. So we're onto the list.
[11:00:37] <sftcd> Start with issue 1183.
[11:00:48] <sftcd> Paul and Doug took actions in Dallas...
[11:00:56] * sftcd has set the topic to: Issue 1183
[11:01:00] <sftcd> Paul?
[11:01:29] <doug_trendmicro@jabber.org> Is there an issue about some type of signature limit?
[11:01:51] --- fenton has joined
[11:02:18] <sftcd> 1183 is about r= in the signature, you (Doug) were to send a mail arguing for this, Paul was to send one against
[11:02:39] <mike thomas> in absence of paul, has there been any support for r=? I haven't seen much
[11:03:00] <doug_trendmicro@jabber.org> If the ISP wishes to send a message that can be safely acted upon, the mechanism offer a level of safety not achieved otherwise.
[11:03:10] <Paul Hoffman> Sorry, I had to move the laundry.
[11:03:34] <Paul Hoffman> I didn't see any interest other than Doug's, so I didn't create a counter-argument.
[11:04:05] <dcrocker> i think paul's point is key. suggestions need to develop support, before they warrant serious debate
[11:04:35] <doug_trendmicro@jabber.org> How does one achieve a safe mechanism in the case of an ISP then?
[11:04:48] <doug_trendmicro@jabber.org> What is a safe email-address?
[11:04:49] <Paul Hoffman> As an extension outside of the base spec.
[11:04:58] <mike thomas> the other question is "is this a core thing or a future thing" this is future thing imo
[11:05:04] <doug_trendmicro@jabber.org> Is a do-not-reply a safe email-address
[11:05:18] <fenton> Mike: exactly the point I was going to make
[11:05:31] <dcrocker> mike, jim: ditto
[11:05:34] <doug_trendmicro@jabber.org> The concern is that without this mechanism the reaction will be to use more domain names in the right-hand side.
[11:05:53] <doug_trendmicro@jabber.org> Without this mechanism, this could create a mess.
[11:05:54] <Paul Hoffman> Doug: these are all semantics that the WG has had problems agreeing on. It should not be part of the base spec unless there is wide agreement. r= probably needs an RFC of its own, and it won't be short.
[11:06:08] <sftcd> Any other voices wanting this to be in base?
[11:06:37] <sftcd> If not, then I suggest we close/reject 1183 and move on.
[11:06:54] <dcrocker> +1
[11:06:58] <jrlevine> +1
[11:07:05] * sftcd has set the topic to: Issue 1184
[11:07:18] <sftcd> Ok so 1184 - "multiple crypto transition"
[11:07:33] <sftcd> Mark took an action but isn't here. Anyone else want to speak to this or will we skip it?
[11:07:41] <fenton> lets move on
[11:07:46] <Dennis Dayman> ditto
[11:07:53] <doug_trendmicro@jabber.org> - When a verifier detects a signature is using a key marked as depreciated, it must verify the existence of an additional signature supported by the signing domain not marked as depreciated, and confirm the correspondence of the signature algorithm with that of the key. - If the verifier supports the algorithm of the signature using a key not marked as depreciated, this signature SHOULD be used instead. - If there are no additional signatures not marked as depreciated, or where the algorithm of the signature is not confirmed to correspond with the key, the message signature for that domain SHOULD be considered invalid.
[11:07:55] <Paul Hoffman> I don't remember the context of this one, but I suggest we leave this alone. Let the sender and recipient guess, just like in all other security protocols.
[11:08:15] <doug_trendmicro@jabber.org> There was the missing element of confirming the algorithm.
[11:08:38] <eric> depreciated?
[11:08:39] <eric> deprecated perhaps?
[11:08:42] --- fenton has left
[11:08:50] <Paul Hoffman> This is all text telling the verifier what to do. We shouldn't be doing that.
[11:08:59] <jrlevine> Did Mark ever provide language? Don't recall seeing it.
[11:08:59] <mike thomas> maybe these somewhat orphaned ones should have a list topic opened and if nobody is interested, we close it
[11:09:02] --- fenton has joined
[11:09:08] <dcrocker> no, probably depreciated. discussing it is a group investment and we need to amortize it.
[11:09:22] <eric> agreed. i've tried to reword everything to provide suggestions, but nothing more wherever possible.
[11:09:33] <doug_trendmicro@jabber.org> This is letting the verifier know there is a depreciated signature being offered to aid the transition.
[11:10:03] <Paul Hoffman> The verifier doesn't need to know the reason. He/she just verifies based on local policy.
[11:10:17] <doug_trendmicro@jabber.org> Without being able to signal this situation, the risk will persist for as long as multiple signatures are needed.
[11:10:23] <dcrocker> anyone else in favor of this?
[11:10:29] <sftcd> (John) I didn't notice a mail from Mark
[11:11:17] <eric> i don't recall seeing anything from mark either.
[11:11:31] <eric> i guess leave this pending for now?
[11:11:38] <sftcd> On the basis that this is a subsidiary issue to the general handling of multiple signatures, I'd be ok with closing this one
[11:11:45] <sftcd> since we'll have to revisit anyway
[11:12:01] <sftcd> Is that correct?
[11:12:06] <eric> ok with me. if some wording shows up that works it can be incoprorated later.
[11:12:13] <doug_trendmicro@jabber.org> Why not get this into base?
[11:12:27] <Paul Hoffman> Doug: because the semantics are unclear.
[11:13:15] <eric> we accepted this in Dallas, and Mark took the action. How about we pester Mark to follow through?
[11:13:30] <sftcd> So let's mark this as close/reject and move on (next is 1196 I think).
[11:13:35] <doug_trendmicro@jabber.org> The small effort to get this resolved would ensure the transition can be safer.
[11:13:41] * sftcd has set the topic to: Issue 1196
[11:14:06] --- tonyhansen has joined
[11:14:10] <sftcd> (Sorry Doug - we'll have to revist later when we write rules for verifying >1 sig anyway, so I think its ok to move on)
[11:14:35] <jrlevine> 1196 looks like the same question, choosing among multiple sigs, combine it?
[11:14:38] <doug_trendmicro@jabber.org> This seems to be the same issue?
[11:14:49] <sftcd> 1196 was where EKR and Russ disagreed about a bidding down type attack
[11:14:52] <mike thomas> This is the issue of relative strengths of hashes, right?
[11:14:58] <sftcd> right
[11:15:10] <doug_trendmicro@jabber.org> That was what my comment was about.
[11:15:16] <Paul Hoffman> I'm with EKR on this one.
[11:15:26] <Paul Hoffman> Doug: this is different.
[11:15:26] <mike thomas> I think I agree with EKR mostly that this might not be an easy scale
[11:15:43] <fenton> I think I'm with ekr too, but don't understand Russ's position fully.
[11:15:54] <doug_trendmicro@jabber.org> The simple flag and algorithm confirmation is all that is needed it would seem.
[11:15:56] <sftcd> So is there any change needed to reflect the EKR position here or is that a NO-OP?
[11:16:01] <Paul Hoffman> Doug: this is not about saying "there is a transition", this is about saying "here are all the algs I included/wanted".
[11:16:23] <Paul Hoffman> EKR's is the no-op; Russ wants an enumeration.
[11:16:36] <doug_trendmicro@jabber.org> Yes, I understand, but the transition is to accommodate a change more gracefully.
[11:16:46] <fenton> doesn't the publication of a key with a particular alg handle this?
[11:16:58] <Paul Hoffman> Jim: I believe so.
[11:17:04] <mike thomas> I think so too
[11:17:10] <dcrocker> these sorts of concerns assume that a receiver does not already know what algorithm(s) to prefer and needs to be protected from allowing one inappropriately. i think the purpose of dkim allows us to easily leave this to the competence of the receiver, and keep dkim that much simpler.
[11:17:20] <doug_trendmicro@jabber.org> A method that assures a means to confirm an unknown algorithm is all that is really needed.
[11:17:55] <sftcd> Jim: to clarify by alg there you mean sig-alg (e.g. rsa-sha256) and not just rsa, right (I can't recall what's in the key records now)
[11:17:59] <doug_trendmicro@jabber.org> I suggested that all future algorithms be expressed as integers to handle binary keys.
[11:18:00] <jrlevine> um, if the receiver doesn't know the alg, how can it even verify the sig?
[11:18:15] <Paul Hoffman> +1 to Dave's message.
[11:18:31] <doug_trendmicro@jabber.org> It only needs to confirm that the sender offered the algorithm that the verifier does not yet handle.
[11:18:40] <mike thomas> I think Jim means the h= in the selector
[11:18:43] <eric> Dave: +1
[11:18:58] <fenton> Stephen: the key record specifies both the hash and sig algorithms, which I think is all we need.
[11:19:28] <doug_trendmicro@jabber.org> If done with text, it must always be done that way then.
[11:19:47] <fenton> Doug: what do you mean, with text?
[11:20:10] <boxley> talking txt vs binary record
[11:20:11] <doug_trendmicro@jabber.org> It would be impractical to transition to text and a table index as is now commonly used.
[11:20:27] <doug_trendmicro@jabber.org> Sorry from text.
[11:20:29] <Paul Hoffman> Doug: this seems completely trivial.
[11:20:36] <doug_trendmicro@jabber.org> No.
[11:20:56] <sftcd> You've lost me now, is this really still 1196?
[11:21:11] <doug_trendmicro@jabber.org> If the signature is text and the key is binary how do they correspond in the case of a new algorithm.
[11:21:24] <mike thomas> I'm completely lost. are we talking about txt vs binary rr's? they're both trivial
[11:21:45] <mike thomas> uh, this is a non issue
[11:21:47] <doug_trendmicro@jabber.org> No. There can not be an assumed translation.
[11:22:08] <Paul Hoffman> Doug: this has nothing to do with 1196.
[11:22:12] <fenton> right. we define the translation when we define the binary rr
[11:22:20] <sftcd> Ok. I detect wandering here. The consensus here on 1196 is with EKR it seems which means close/reject again on that issue.
[11:22:20] <doug_trendmicro@jabber.org> No.
[11:22:23] <mike thomas> +1 pau
[11:22:32] <sftcd> Next issue is 1224 (gulp!)
[11:22:50] <sftcd> I don't think we can sort this, but can someone take an action to write us an essay or something?
[11:22:59] * sftcd has set the topic to: Issue 1224
[11:23:04] <mike thomas> I've got one question though
[11:23:12] <sftcd> 1224 is "DKIM and mailing lists"
[11:23:14] <fenton> I have been thinking about this a bit, I can write an essay
[11:23:21] <mike thomas> through all of that, does anybody think something needs to change in the base spec?
[11:23:25] <mike thomas> I don't
[11:23:34] <sftcd> for 1196, I think the conclusion was "no"
[11:23:39] <jrlevine> I've argued about this, agree no changes needed
[11:23:51] <mike thomas> then we can close it, I think
[11:23:56] <fenton> We do need to make sure that -base has everything it needs to handle lists, but I also think it's all set.
[11:24:04] <Paul Hoffman> +1 to no changes needed. This is good fodder for a BCP document.
[11:24:12] <mike thomas> yes
[11:24:14] <eric> i do think that we need to consider this. not for base though.
[11:24:29] <doug_trendmicro@jabber.org> One minor issue remains about the expression of algorithms to ensure a future transition in algorithms.
[11:24:51] <sftcd> I'd like to see the JIm's essay first before we close 1224 though
[11:24:55] <doug_trendmicro@jabber.org> A confirmation is needed.
[11:25:18] <jrlevine> I'm happy to kibitz on the essay, since I think Jim and I are at the opposite ends of the mailing list argument
[11:25:48] <sftcd> by kibitz you mean "arm wrestle Jim off-list" ?
[11:26:03] <boxley> I think we are good for mailing lists in base, its when we discus dkip that lists will be in the forefront
[11:26:16] <jrlevine> We say "ensure that the document expresses the divese viewpoints of the community"
[11:26:20] <mike thomas> shouldn't we just defer this to the bcp? it's a little early -- we're just now generating our own data
[11:26:50] <jrlevine> I'd hope that Jim and/or my thing would be fodder for BCP, agree that base needn't wait for it
[11:27:05] <sftcd> we could close the issue for base and create a new issue for the overview I-D then?
[11:27:17] <boxley> close for base
[11:27:22] <dcrocker> +1
[11:27:28] <Paul Hoffman> +1 to this being in the overview, not its own document.
[11:27:28] <mike thomas> is overview going to transmogrify to bcp?
[11:27:29] <fenton> Either way. Happy to kibbutz with John if he wants
[11:27:30] <tonyhansen> +1
[11:28:12] <sftcd> mike: parts of the overview might, parts might not, guess we'll see...
[11:28:13] <fenton> But I'm not flying to Trumanville for an arm wrestling contest.
[11:28:19] <jrlevine> I
[11:28:21] <jrlevine> I
[11:28:31] <jrlevine> I'll be in California soon enough. Next, please?
[11:28:41] <sftcd> ok so close 1224 and open a new equivalent on the overview is the result.
[11:28:56] <sftcd> next is 1231 I think (problematic refernces)
[11:29:01] * sftcd has set the topic to: Issue 1231
[11:29:18] <fenton> Remind me what the problematic refs are
[11:29:21] <jrlevine> anything on 1229?
[11:29:37] <sftcd> ok - let's hop back to 1229
[11:29:45] <jrlevine> (mostly a question for Paul)
[11:29:53] <Paul Hoffman> [ID-DKIM-RR] "DKIM Key Resource Records (To be written)", draft-dkim-dkk-rr-xx (work in progress), 2005.
[11:30:18] <mike thomas> ?
[11:30:20] <sftcd> In Dallas Paul agreed to be our EAI liasion...whats up there Paul?
[11:30:33] <Paul Hoffman> 1229: I have been lax on this. Will engage this week.
[11:30:42] <dcrocker> eric was going to remove references to dns queries and instead specify what information was needed as the result of a query (no matter how it was done.) this moves query mechanism to be outside of base.
[11:31:02] <doug_trendmicro@jabber.org> The encoding should not affect the encoding of i= or g=
[11:31:09] <mike thomas> uh, I don't remember concensus for that
[11:31:29] <eric> i'll have to look to see what i've got for DNS references. i did some, but probably not enough. i see i still have thrf to ID-DKIM-RR
[11:31:54] <eric> ah
[11:32:09] <Paul Hoffman> Also, Eric: please remove the normative reference to the OpenSSL doc.
[11:32:11] <eric> actually if i delete all references to dns, we also lose the _domainkey subdomain, which i think is importnat.
[11:32:16] <doug_trendmicro@jabber.org> Should that merge with DNS binary RR?
[11:32:26] <fenton> A related question is whether -base is viable without having defined the DKIM-RR
[11:32:28] <eric> wording now:
[11:32:31] <mike thomas> right... let's not go there
[11:32:35] <tonyhansen> _domainkey refs need to stay
[11:32:52] <Paul Hoffman> +1 to Tony
[11:33:02] <eric> oh bother, sorry, cut and paste doesn't work from xmleditor
[11:33:24] <eric> basically, says there is a DNS binding that MUST be supported.
[11:33:27] <eric> uses _domainkey
[11:33:36] <eric> two RR types, DKK and TXT
[11:33:45] <eric> it's this last bit that probably needs to go.
[11:33:50] <dcrocker> eric, the problem is that resolving the dns issues is going to ensure a much longer completion schedule for the core ability to sign/validate a single signature. this is why i have tried to lobby for making the base narrower and creating a 'systems' spec the encompass these larger issues.
[11:34:21] <eric> if there's absolutely no way defined to get a key, then it's not clear how useful getting the base spec out will be.
[11:34:22] <mike thomas> we cannot have a base without a binding to at least one query mechanism
[11:34:29] <sftcd> dave, but doesn't a programmer have to be told the formatting of the public key
[11:34:29] <Peter Koch> by the way: there is no IANA "prefix" registry
[11:34:41] <doug_trendmicro@jabber.org> Until now?
[11:34:54] <Paul Hoffman> Dave is right. The IAB's DNS RR policy says we should have a binary format, but it is not clear we really need one if we are using _domainkey.
[11:35:36] <mike thomas> my preference is to separate out DKIM RR, and the only normative ref is for the TXT encoding in -base
[11:35:39] <doug_trendmicro@jabber.org> This becomes an issue with 2048 bit keys and the risk of exceeding the 512 byte limit of DNS messages.
[11:35:54] <mike thomas> DKIM RR can define the new query method and extend base
[11:36:11] <sftcd> There may also be a "political" issue if base only defines a TXT and says nothing about DKK (if I'm not mistaken).
[11:36:11] <Paul Hoffman> The use of prefixes changes the whole "do you need a new RR" debate, making it more problemsome.
[11:36:13] <sftcd> Its a problem.
[11:36:35] <Peter Koch> sftcd: not 'political' but 'architectural', but: yes
[11:36:43] <sftcd> I sit corrected:-)
[11:36:43] <Paul Hoffman> Stephen: the political issue exists either way.
[11:36:58] <mike thomas> We do have it in our charter. Proceeding this way the worst that happens is that DKIM RR needs to be bundled with -base
[11:36:59] <fenton> Stephen: that was what I meant by "is -base viable without dkk"
[11:37:00] <doug_trendmicro@jabber.org> Perhaps the DKIM RR document to make the effort to explain what is normally conveyed in a response.
[11:37:22] <mike thomas> it's viable if the txt encoding is there.
[11:37:23] <boxley> Agree with Mike, we need to describe functionality of parts not technically how we do a query
[11:37:45] <sftcd> Ok, we're not going to solve this now. But the quicker a DKK doc pops out the better I guess. Let's leave this open and move on?
[11:37:46] <fenton> If -base won't make it through IESG without DKK, we might as well leave the reference there.
[11:38:02] <Paul Hoffman> We need to define the TXT query for implementers. If that gets rejected, we can deal with the new RR.
[11:38:02] --- fenton has left
[11:38:11] <dcrocker> steve, a programmer needs to be told many things. i am not suggesting that the dns issues are not important, but that there is immediate benefit from a sign/validate a single identity, before we resolve various other systems issues. in other words, the base is useful even before we agree on larger systems issues.
[11:38:11] <sftcd> Next seems to be 1236, but I don't recall the detail...anyone?
[11:38:12] <mike thomas> My suggestion is to _NOT_ put it in there, and see if we get pushback
[11:38:14] --- fenton has joined
[11:38:16] * sftcd has set the topic to: Issue 1236
[11:38:17] <Paul Hoffman> We can also ask our ADs to find out now how important this is.
[11:38:39] <tonyhansen> we *could* create a preliminary dkim dns draft that has current TXT text in it, with place holders for DKK. Then change base to use a normative reference
[11:38:54] <sftcd> did I move on too qiuckly?
[11:39:00] <Paul Hoffman> Stephen: yes.
[11:39:11] <dcrocker> tony, do you mean make the base depend upon the dkim dns draft?
[11:39:12] * sftcd has set the topic to: Issue 1231 again then
[11:39:16] <doug_trendmicro@jabber.org> I think that 1236 was hector, but he is not here.
[11:39:21] <Paul Hoffman> Tony: I propose we don't go that far. Just define TXT unless our AD says the IESG won't allow it.
[11:39:30] <mike thomas> +1 paul
[11:39:55] <sftcd> We did ask. The answer was along the lines of "if you want that fight then we may support you, but it'll be an IETF-wide squabble"
[11:39:56] <doug_trendmicro@jabber.org> In the mean time create the DKIM RR draft.
[11:40:11] <Paul Hoffman> Stephen: get something more definitive.
[11:40:20] <mike thomas> so the worst that happens is we get stalled behind dkrr
[11:40:30] <fenton> Mark is pretty far along with the DKIM RR draft, but doesn't have it ready to publish yet
[11:40:31] <mike thomas> which you'd get if you had a normative ref
[11:40:34] <eric> i'm not wild about getting stalled.
[11:40:34] <mike thomas> anyway
[11:40:40] <Paul Hoffman> Doug: no, not if we don't need it. And I fully disagree with your "need" based on 2048-bit keys and very long names and so on.
[11:40:42] <eric> i think it will be contentious.
[11:40:56] <dcrocker> the dns purists have been quite effective in derailing near-term approaches like ours, absent complete resolution of the "preferred" long term approach. that is going to hurt finalization of the base spec.
[11:41:06] <eric> i would like some way to finesse this if possible. but i think we have to define the TXT binding in -base.
[11:41:11] <sftcd> (Paul - I'll try get a quotable AD answer via email)
[11:41:27] <Peter Koch> I'm not very confident that specifying TXT (as in TXT RR, not text format) and only 'promising' something application specific is a successful approach. But willing to discuss offline.
[11:41:42] <mike thomas> it's in our charter... it's more than a promise
[11:41:55] <doug_trendmicro@jabber.org> Paul, why is the size constraint not an issue?
[11:42:01] <tonyhansen> what does q=dns mean? I'd like to suggest making it mean *only* a TXT lookup, and define that lookup within base. Then when DKK comes out, define q=dnsrr (or something like that) that has the new semantics.
[11:42:16] <mike thomas> I agree tony
[11:42:20] <sftcd> not bad tony!
[11:42:20] <eric> +1
[11:42:22] <fenton> tony: +1
[11:42:26] <boxley> +1
[11:42:32] <jrlevine> q=dnsrr +1
[11:42:34] <Dennis Dayman> +1
[11:42:35] <Paul Hoffman> Tony scores!
[11:42:39] <Dennis Dayman> hat trick
[11:42:45] <Peter Koch> +/- 0
[11:42:49] <sftcd> eh?
[11:42:52] <fenton> Tony: except "it has new syntax", not "semantics"
[11:42:53] <eric> solves the "what order to query them" problem too.
[11:43:32] <sftcd> Ok. Tony's re-interpretatoin of q= seems to have consensus here. Tonry will you write a mail to the list on this? (Or Eric or someone...)
[11:43:32] <dcrocker> +1
[11:43:41] <tonyhansen> no, I meant semantics, because it would also define the order of lookups as well as the syntax.
[11:43:58] <tonyhansen> (fallback to TXT, etc.)
[11:44:05] <eric> tony, you send a message to the list, i'll get it into -02b.
[11:44:10] <tonyhansen> ok
[11:44:37] <mike thomas> one thing to be careful here is to not make a normative reference to dkrr
[11:44:47] <fenton> tony: order of lookups: I thought you looked up either TXT or DKK, not both, depending on what q= says
[11:44:54] <dcrocker> small suggestion: make this first query method be named dnstxt. makes clear its scope.
[11:45:05] <eric> q= can be a list.
[11:45:12] <tonyhansen> ooh
[11:45:14] <eric> dave: ++
[11:45:14] <fenton> ok, yeah
[11:45:42] <sftcd> great action for 1231 is on Tony.... moving on again...issue 1236 was hector's anyone want to talk to that?
[11:45:48] * sftcd has set the topic to: Issue 1236
[11:45:58] <eric> 1236: this was essentially listing the various ways a verification could fail. done in -02b, although we may want more (or less) detail.
[11:46:12] <sftcd> so best left 'till -02 pops out then?
[11:46:17] <tonyhansen> is 02b available anywhere?
[11:46:20] <eric> i think that's probably the easiest
[11:46:23] <jrlevine> it's a swamp, failures have no semantics so don't see the point
[11:46:25] <eric> so far, only on my laptop.
[11:46:41] <eric> i ran a draft by a couple of people and just (yesterday) got their comments incorporated.
[11:46:51] <eric> i think i'll take what i get today and get -02 out from that.
[11:47:00] <fenton> Let's leave 1236 open for now. I have concerns, but better to wait till we have something concrete to discuss
[11:47:04] <sftcd> ok leave 1236 open next is 1255 it seems (optional exponent)
[11:47:09] * sftcd has set the topic to: Issue 1255
[11:47:31] <sftcd> I asked for this. no pressing reason other than every other RSA protocol allows the exponent be included and we don;t
[11:47:56] <mike thomas> where is it included? Is this not in the PEM encoding?
[11:48:10] <Paul Hoffman> Can we punt on this and say that if we want exponents later, we need to have a new algorithm syntax then?
[11:48:12] <eric> does merge the crypto alg with the record syntax.
[11:48:13] <fenton> I'd like Jon Callas's opinion on this
[11:48:42] <Paul Hoffman> We also will need this if we use ECC, but that's years off, I suspect.
[11:48:58] <sftcd> (Paul - if so we need to define RSA as rsa with e=65537 in the text)
[11:49:05] <sftcd> ECC is very much later I hope
[11:49:43] <mike thomas> is PEM encoding implicitly e=65537?
[11:49:45] <doug_trendmicro@jabber.org> Agree with eric.
[11:49:51] <Paul Hoffman> +1 to giving the exponent in the text.
[11:50:58] <sftcd> so leave open pending more input or close re-defining rsa as (rsa with e=65537) ?
[11:51:19] <Paul Hoffman> Close.
[11:51:30] <fenton> close
[11:51:33] <jrlevine> close, not useful to offer the option
[11:51:51] <doug_trendmicro@jabber.org> Define as part of algorithm and close.
[11:52:19] <sftcd> seems fairly good consensus - eric will you include a line with the string 65537 then?
[11:52:35] <eric> roger that
[11:53:07] <sftcd> nearly out of time folks - next one is use of v= do we want to tackle that or declare victory for today?
[11:53:20] <Paul Hoffman> Let's do v=: it's mine. :-)
[11:53:35] * sftcd has set the topic to: Issue 1258
[11:53:38] <mike thomas> I have no objection to it
[11:53:42] <eric> (i thought we had another hour)
[11:53:46] <sftcd> Paul...off you go
[11:53:51] <Paul Hoffman> Seriously, it is also very relevant to Eric's next draft.
[11:54:03] <sftcd> (Nope just one hour slots, but running over is fine with me)
[11:54:20] <Paul Hoffman> We are changing syntax between drafts; we should be able to signal that easily in the protocol.
[11:54:36] <mike thomas> does anybody have heartburn with doing this? I don't
[11:54:44] <eric> as i recall, mark was the one who was most adamant against v=. But at this point he's OK as long as the keys remain back compat.
[11:54:48] <eric> or that's my interp.
[11:54:59] <doug_trendmicro@jabber.org> Does draft 03 go to version 2?
[11:55:02] <sftcd> So you want a new v= value for each incompatible change? or for each draft? or when we specifcally decide?
[11:55:15] <mike thomas> right now I'm basing v0 v1 off of bh, which is sort of hokey
[11:55:19] <Paul Hoffman> Doug: the identifiers used don't matter as long as they are unique.
[11:55:40] <eric> i'm inclined to use 0.1, 0.2, ... and start at v=1 for the published version.
[11:55:44] <doug_trendmicro@jabber.org> Someone will want to know what to ignore then.
[11:55:56] <Paul Hoffman> +1 to Eric's suggestion. Easy and understandable.
[11:56:06] <dcrocker> +1
[11:56:20] <doug_trendmicro@jabber.org> Eric's comment looks okay.
[11:56:22] <tonyhansen> +1 0.1, 0.2, etc.
[11:56:24] <sftcd> asks again: when is the value incremented?
[11:56:37] <eric> when a verifier cares.
[11:56:39] <Paul Hoffman> Answer: at every draft.
[11:56:41] <doug_trendmicro@jabber.org> Per draft it would seem.
[11:56:52] <sftcd> even if the draft only fixes typos?
[11:57:03] <Paul Hoffman> We change semantics in drafts, and that should be noted as well as syntax changes.
[11:57:06] <eric> no, i don't think so.
[11:57:17] <mike thomas> this really means that a receiver <= 1
[11:57:25] <mike thomas> would be looking for...
[11:57:26] <eric> if the changes really have no effect on the implementation, keep the version number.
[11:57:37] <tonyhansen> and if v= is missing, a receiver would use current heuristics of looking for bh=, etc.
[11:57:39] <eric> but that's hypothetical.
[11:58:00] <dcrocker> what is the purpose of the version number? how is it to be used? what happens when a receiver does not support the received version number? is that the effect we want?
[11:58:00] <sftcd> so how about we increment only when there's explicit consensus for that due to syntatic/semantic changes?
[11:58:01] <tonyhansen> so far every draft has had *some* semantic change
[11:58:04] <mike thomas> right now, what I'd do is just make certain it's there, and not > 1
[11:58:05] <Paul Hoffman> Sure, that's fine, but don't make a big deal of deciding. There are few implementations, and they are (hopefully) actively maintained.
[11:58:56] <doug_trendmicro@jabber.org> Only increment on functional changes for the verifier.
[11:58:58] <sftcd> someone want to synopsise the result for 1258?
[11:59:02] <Paul Hoffman> Dave: to tell the receiver what it must know about the signature.
[11:59:23] <eric> i can summarize.
[11:59:37] <mike thomas> frankly, just setting it to just 1 with the expectation that it's not stable is probably fine too
[11:59:46] <sftcd> off ya go so...(btw: I'm near timing out, sorry)
[11:59:47] <Paul Hoffman> See? We got another one in and kept under the hour. :-)
[11:59:50] <eric> that way i can be sure that the text will match the message.
[12:00:44] <sftcd> I propose that we close in a minute (I assume Eric's typing)
[12:00:55] <eric> i'm here.
[12:00:57] <sftcd> If you've any AOB items get ready to raise your hand
[12:01:15] <eric> shall i send -02b to the list before submission?
[12:01:24] <eric> or just send for pub?
[12:01:30] <eric> i would want quick turnaround.
[12:01:38] <mike thomas> just pub, I think
[12:01:38] <Paul Hoffman> Please just submit for publication. That's what drafts are fore.
[12:01:41] <sftcd> just publish and to list in parallel
[12:01:43] <Paul Hoffman> s/fore/for/
[12:01:53] * sftcd has set the topic to: AOB
[12:01:55] <eric> ok, probably tomorrow
[12:02:05] <sftcd> any AOB topics? (I have one item)
[12:02:11] <doug_trendmicro@jabber.org> There were a few topics not reviewed?
[12:02:14] <Paul Hoffman> Stephen: let's do this again in two weeks and knock off more open issues.
[12:02:19] <tonyhansen> eric: you may have caught this nit. in -01, q= section, s/iis/is/
[12:02:35] <mike thomas> I agree with paul
[12:02:37] <sftcd> mine is a little thing: we got Russ' review of threats and Jim is going to re-issue. Nothing big.
[12:02:41] <sftcd> That's mine.
[12:02:47] <eric> tony: i'll check it.
[12:02:49] <sftcd> Ok to doing it again. Want a longer slot or not?
[12:03:00] <Paul Hoffman> No, let's keep it focused.
[12:03:01] <eric> i'm good for 2 hours.
[12:03:05] <jrlevine> prefer one hour
[12:03:14] <dcrocker> 2 hrs
[12:03:15] <Dennis Dayman> 2
[12:03:18] <doug_trendmicro@jabber.org> Either is okay..
[12:03:19] <boxley> 2
[12:03:19] <mike thomas> I'm good for longer
[12:03:22] <Peter Koch> 1
[12:03:23] <sftcd> 1.5 hours then
[12:03:27] <tonyhansen> :-)
[12:03:27] <Dennis Dayman> ha
[12:03:29] <mike thomas> :)
[12:03:32] <jrlevine> better make a big pot of coffee
[12:03:44] <sftcd> No other AOB items?
[12:03:58] <sftcd> we're done then...thanks.
[12:04:02] <sftcd> bye for onw
[12:04:04] <mike thomas> kewl
[12:04:05] <Dennis Dayman> later
[12:04:05] <boxley> by
[12:04:07] --- boxley has left
[12:04:08] <Paul Hoffman> Cheers.
[12:04:11] <eric> ciao
[12:04:13] <tonyhansen> ta ta
[12:04:14] --- Dennis Dayman has left
[12:04:19] <fenton> bye!
[12:04:26] <Paul Hoffman> Someone will tell Eliot to read the log, yes?
[12:04:30] <sftcd> that'd be me
[12:04:31] <Paul Hoffman> s/tell/ask/
[12:04:53] <sftcd> I guess I'll send a summary note to the list too
[12:05:04] <Paul Hoffman> Stephen: yes, definitely.
[12:06:47] --- tonyhansen has left
[12:06:53] --- sftcd has left
[12:07:27] --- Peter Koch has left
[12:07:37] --- eric has left
[12:08:14] --- jrlevine has left
[12:08:15] --- fenton has left
[12:08:45] --- doug_trendmicro@jabber.org has left
[12:12:17] --- Paul Hoffman has left
[14:02:47] --- dcrocker has left
[21:09:19] --- dcrocker has joined