[02:26:04] --- bruce has joined
[02:26:46] --- bruce has left
[02:27:50] --- bruce has joined
[09:51:09] --- bruce has left
[09:51:40] --- bruce has joined
[09:52:42] <bruce> lag test
[11:25:08] --- bruce2 has joined
[11:25:12] --- bruce2 has left: Disconnected
[11:25:58] --- bruce has left: Replaced by new connection
[11:26:16] --- bruce2 has joined
[11:46:48] --- marka-isc has joined
[11:47:53] --- wes5141 has joined
[11:48:00] --- wes5141 has left
[11:49:52] --- wes has joined
[11:49:57] --- mike has joined
[11:50:15] --- nov has joined
[11:51:27] --- yone has joined
[11:51:35] --- edinburgh_craig has joined
[11:52:22] --- yone has left
[11:52:27] --- yone has joined
[11:52:52] --- dblacka has joined
[11:53:24] --- dblacka has left
[11:53:54] --- yone has left: Replaced by new connection
[11:53:54] --- yone has joined
[11:53:54] --- yone has left
[11:54:32] --- yone has joined
[11:54:36] --- dblacka has joined
[11:55:10] --- remowilliams has joined
[11:56:02] --- jaap has joined
[11:56:18] --- miek has joined
[11:56:22] --- raj has joined
[11:57:45] --- peterd has joined
[11:58:08] --- rpayne422 has joined
[11:58:59] --- amarine has joined
[11:59:22] --- Hollenbeck has joined
[12:02:06] --- ggm has joined
[12:02:13] <peterd> 2538bis request for input
[12:04:12] <amarine> am i in the right room for the current mtg?
[12:04:18] <ggm> yes.
[12:04:25] --- ripple has joined
[12:04:26] <amarine> ok thx :)
[12:04:37] <ggm> [sorry.. ggm was late in the door]
[12:04:47] <amarine> slacker
[12:04:52] <ggm> [slide: ecc key draft]
[12:05:10] <ggm> Q from chair: SHA1 diffs, longer SHAs. why not go to longer SHA?
[12:05:40] <ggm> Don Eastlake: this would define them all, the longer SHAs are not that common, still MD5 only mandatory. recommends SHA1/full and SHA1/196s and MAY for everything else. people not jumping to longer SHAs
[12:05:51] <ggm> Liman: need to discuss
[12:06:36] <ggm> Don: if somebody wants to not define some, we can do that. take to ML? WG last call good mechanism to force.
[12:06:50] <ggm> Don: ECC key. 5th revision under current name. was under another name before that.
[12:06:53] --- struk has joined
[12:06:58] <ggm> [sldie: ECC intro]
[12:07:08] <ggm> tend to be much more compact.
[12:07:33] <ggm> personal impression: basic concept is unencumbered, need standard interop, but many patents relating to optimizations. but basic concept is free
[12:07:46] <ggm> current draft defines only key format. earlier drafts had sig format too
[12:08:04] <ggm> concerns about multiple algs to sign zones, sig part should go back in. discussed on ML. posted comments
[12:08:09] <ggm> [slide: problems/Qs]
[12:08:24] <ggm> needs clarifications. define Alg #4, reserved for ECC in all current drafts.
[12:08:27] <ggm> add back sigs,
[12:08:38] <ggm> should be generally applicable.
[12:08:50] --- Suz has joined
[12:09:00] <ggm> a Q brought up, is it too general format? all possible ECC keys. more compact for more common kinds. can define esoteric ones.
[12:09:09] <ggm> not fully up to boilerplate, old draft updating
[12:09:22] <ggm> Steve Crocker: widely deployed in browsers/OS etc?
[12:09:38] <ggm> [Olaf is a WG chair nazi and reminds people to state name]
[12:09:58] <ggm> Don: closer to NO than YES because of licencing problem. not free libs
[12:10:03] <ggm> Ben Laurie: OpenSSL has it.
[12:10:13] <ggm> Don ok wrong. YES its out there in code
[12:10:26] <ggm> Don recommend WG last call on TSIG SHA. pretty good shape.
[12:10:31] <ggm> will revise ECC. needs more work.
[12:10:36] --- ogud has joined
[12:10:41] <ggm> plan new draft.
[12:10:55] <ggm> Olaf: take action to produce WG last call for first doc.
[12:11:13] <ggm> Olafur send comments to list.
[12:11:22] <ggm> [if I said liman, I meant Olafur btw -ggm]
[12:11:36] <ggm> Roy Arendts -qr clarification
[12:11:55] <ggm> Olaf draft is so short fits on one slide so did so [laughter]
[12:12:35] <jaap> More time to connect his machine then to read the draft
[12:13:01] <ggm> Found impls which respond to responses.
[12:13:51] <ggm> comment was: show RFC which says illegal. implicated in 1034/5 but not explicit.
[12:14:00] --- jas has joined
[12:14:02] <ggm> 'we just try to be liberal" -not being conservative
[12:14:25] <ggm> easy to show them responding. respond to self.. server goes offline ... try to be nice. one-line draft.
[12:14:31] <ggm> request WG item please. trivial.
[12:14:47] <ggm> Olaf. hum for acceptance. if accepted, will issue WG last call immediately.
[12:15:14] <ggm> Mike St Johns how long to wait?
[12:15:42] <ggm> Roy. server keeps state. looks up in DB, gives response. if recieve response, will never ever give response
[12:16:09] <ggm> Mike from clients PoV when do you say 'its now unsolicited' ? ie if sent earlier, when Q lost, then becomes ;orphan;
[12:16:20] <ggm> Olaf. its about Q/R bit issue
[12:16:37] <ggm> Roy I understand Q. its not a response to a 'dead' Q, its a response to NO Q
[12:16:58] <ggm> Olaf. accepted at WG document, will appear after IETF,
[12:17:17] <ggm> [offline mutterings]
[12:17:27] <ggm> Ed Lewis on wildcard clarifications
[12:18:22] <ggm> Comments: not just clarify, changes rules. take 'clarify' out of name
[12:18:51] <ggm> other comments, since so no longer clarification but about wildcards, why not discuss all things about wildcards? significantly DS and NSEC.
[12:19:06] <ggm> not well understood at time or originiation. now worth effort to specify
[12:19:14] <ggm> need to work out if 04 made it under the wire.
[12:19:25] <ggm> came up with problem with DS/NSEC
[12:19:40] <ggm> [slide]
[12:20:47] <ggm> some people say "stay liberal" -if you do odd things, you get odd results.
[12:20:52] <ggm> others want to outlaw bad stuff.
[12:20:59] --- mstjohns has joined
[12:21:20] --- pawal has joined
[12:21:42] --- Mark has joined
[12:21:59] <ggm> document says wildcards 'not normal text' and found para. sidebar in 1034. 'the result of a * query should not be cached' -this is unusual. we probably want to spend time on what this means, role of new document to make this clear? or, go to other options tbd?
[12:22:10] <bruce2> [if you outlaw it, then you'll get code which won't deal with 'odd' cases and possibly bork in really bad ways]
[12:22:17] --- Jim Galvin has joined
[12:22:49] <bruce2> [on the assumption that odd cases can never happen]
[12:23:14] --- tskj has joined
[12:24:20] <ggm> tried an example to think about in detail, needing to do DS. show that wildcard with matching Qtype, can reply with NSEC belonging to different zone to the expected one. how can be auth for NS rec, when not auth for name?
[12:24:31] <ggm> floor comment [this is ugly]
[12:25:03] <ggm> suggestions floating around. outlaw zones with * NS and other 'special' types.
[12:25:22] <ggm> exempt certain types from wildcard processing
[12:25:42] <ggm> Intstruct DNSSEC validators, to ignore 'problem'
[12:26:05] <ggm> specify * labels inherently different, can only have certain types, cannot be sub-domained.
[12:26:45] --- mstjohns has left: Replaced by new connection
[12:26:46] --- mstjohns has joined
[12:26:46] --- mstjohns has left
[12:26:52] --- mstjohns has joined
[12:27:41] <ggm> Bill Manning seen discussions on ML. thought some of these suggestions shot down as unworkable/unwise. how long listen to religion at mike?
[12:27:53] <ggm> Ed: at mike, 5mins, ML unbounded?
[12:28:09] <ggm> worth starting discussion. we do rehash things, but we find things we didn't know 'back then'
[12:28:52] <ggm> Bill of the 4 suggestions, 1, 2, 4 ludicrous, only 3 makes sense (ie only tell validaters to ignore works for bill)
[12:29:12] <ggm> Sam: don't understand 3 [laughter] what do you tell validaters to do?
[12:29:20] <ggm> Ed just 'thats ok. it should be that way'
[12:29:22] <ggm> Sam and follow?
[12:29:31] <ggm> Ed no. just to ok it. not to do iterative query processing.
[12:29:46] <ggm> Mark A. leads to inconsistent state
[12:30:20] <ggm> Just answer to NS Q. its not referral to children. Yet to understand why Ed came up with this. leads to inconsitencies in cache after doing this. depending on Q orders.
[12:30:55] <ggm> Ed. there are interdependencies. tells validator not to kick out data. fact that its signed from different auth from that it came from is noted. caches get 'misled
[12:30:55] <ggm> '
[12:31:06] <ggm> Sam can you use it to implement Opt-in?
[12:31:11] <ggm> Olaf don't go there. move to next topic.
[12:31:21] <ggm> Important people look at this. want to get draft closed. move on.
[12:32:10] <ggm> Olafur will formalize discussion on ML. issue tracker.
[12:32:38] <ggm> Future work: Denial of Existence. Olaf speaking.
[12:33:12] <ggm> before we closed of DNSSECbis, (in RFC edQ) we started discussion on NSEC enumeration problem. has continued on and off for while. Asked ML if critical mass to work on problem.
[12:33:23] <ggm> Answer on and off list, gathered sufficient money and people to proceed with work.
[12:34:13] <ggm> What we did is call requirements eds, couple of people, to see if we can get reqts doc moving, assess what is written in doc, commonalities, find and clarify, prioritize, split hard reqts and desireables, give order of preferences. has been done. will present.
[12:34:32] <ggm> also scanned solution space as known, looked at reqts/desireables, see how they matched. will get back to that after presentation
[12:35:44] <ggm> Rip Loomis. reqts relating to signed proof of non-existence (rip and ben)
[12:35:47] <ggm> slides will go online asap.
[12:35:59] <ggm> draft is 01 status. no feedback on/off list.
[12:36:15] <ggm> informal discussions as outlined by olaf. new reqts, clarifications
[12:36:18] <ggm> [slide on terminology]
[12:36:29] <ggm> [slide 3 in fact]
[12:37:20] <ggm> [slide4: group enumeration and exposure]
[12:37:42] <ggm> boiling down a bunch of things to 'DNSSECter shoud not make it easier to enumerate zones than it is, in plain DNS"
[12:37:52] --- struk has left
[12:37:56] <ggm> believe is high prio requirement.
[12:38:32] <ggm> probably have AXFR disabled if you want this in plain DNS.
[12:38:52] --- ed has joined
[12:39:09] <ggm> threshold: "enumaration is at least non-trivial."
[12:39:33] <ggm> concrete test is that random zone data is infeasible to enumerate . - dictionary attack defeat
[12:39:44] <ggm> [slide 5 zone size]
[12:40:01] --- admcd has joined
[12:40:03] <ggm> believe is 'nice to have' but NOT a true requirement. (this is worrying if people can guess how large a zone is)
[12:40:19] <ggm> request comments
[12:40:32] <ggm> [slide 6 compat & transition]
[12:40:41] <bruce2> [are most zones indeed 'random'?]
[12:41:04] <ggm> "current DNSSECbis, with NSEC, should not be affected by future NSEC++ deployment (if they currently don't care about zone enumeration)"
[12:41:14] <ggm> this is high priority requirement.
[12:41:24] <ggm> [slide 7 empty non terminals]
[12:41:31] <ggm> low prio requirement. did not reword
[12:41:40] <ggm> [slide 8 DNSSEC adoption and zone growth]
[12:41:57] <ggm> nice to have, medium prio desireable. may bog down WG considering this
[12:42:10] <ggm> [slide 9 non-overlap of denyal recs with regular namespace]
[12:42:31] <ggm> did not reword reqt. not sure can address. cannot protect against all foolish actions. comments welcome.
[12:42:58] <ggm> eg people lodging hashes as names, bunch of silly things, ways round them
[12:43:19] <ggm> [slide 10 online exposure of signing keys]
[12:43:23] <ggm> did not change. nice to have. (ie medium priority desireable)
[12:44:10] <ggm> can live with this. online keys may work for some, not others. trade-offs. something in one of the solutions has to provide for this. (preventing enumeration without requireing keys online)
[12:44:15] <ggm> [slide 11" zone sign cost]
[12:44:26] <ggm> did not reword. medium priority desireable.
[12:44:35] <ggm> [slide 12" DoS pre3vention/symmetric cost]
[12:45:04] <ggm> should not make DoS significantly more effective than DNSSECbis. in current recursive validating resolver, its already ripe for DoS. raised bar as high as current.
[12:45:27] <ggm> believe low priority desireable. because DNSSEC makes DoS easier in general. not sure realistic requirement.
[12:45:50] <ggm> [slide 13: sensible complexity]
[12:46:18] <ggm> caching, wildecards, CNAMEs, DNAMES should work without significant increases in complexity client-side
[12:46:41] <ggm> operational usage, validator, implementation. medium priority desire. 'like to have' message, but didn't make requirement
[12:46:49] <ggm> [slide 14: completeness]
[12:47:04] <ggm> the restated stuff is almost completely orthogonal to original (!)
[12:47:37] <ggm> should not be a proof of non-existence for any valid data in the zone. which denies other behaviours and is in conflict
[12:47:42] --- robertml has joined
[12:47:44] <ggm> [slide 15: DNS purity]
[12:48:17] <ggm> awareness issue. listing as desireable. issues like hashes colliding with (future) real data needs
[12:48:24] <ggm> [slide 16: replay]
[12:48:52] <ggm> DNSSECbis doesn't allow replay. but NSEC covering span, valid sig, create rec inside span, can replay NSEC and prove non-existence.
[12:49:09] <ggm> reworded to make it clear its a 'no more effective than at present" requirement.
[12:49:19] <ggm> [slide 17: security during zone transition]
[12:49:40] --- johani has joined
[12:49:51] <ggm> new requirement. avoid making data insecure, partly secure, during transition. avoid inconsistent data.
[12:50:04] <ggm> believe at least highly desireable, possibly a hard requirement.
[12:50:12] <ggm> [slide 18 universal signing]
[12:51:01] <ggm> new requirements. if it can be signed with DNSSECbis, then can be signed with DNSSECter. believe this is all zones, but do not have proof. if it can't be signed in DNSSECbis, wont make requirement can in -ter.
[12:51:03] <ggm> hard requirement
[12:51:10] <ggm> [slide 19: universal signing]
[12:51:23] <ggm> new requirement, should be possible, but highly desireable.
[12:51:31] <ggm> [slide 20 universal signing]
[12:52:01] <ggm> new requirement. if cant sign with NSEC++ for constraints/methodoloogy in -ter, need to be able to define them.
[12:52:12] <ggm> [slide 21 NSEC++ seen from NSEC only resolveer]
[12:52:47] <ggm> should appear as consistent as unsigned case. never want user to see inconsistent data. at least highly desireable, perhaps hard requirement
[12:53:10] <ggm> came up as ed.s talked, groundrules for transition came out. want to avoid flagday.
[12:53:20] <ggm> [slide 22: priority order]
[12:53:53] <ggm> editors belief of the order of priority. by group codes in new draft, its 1, 3, 13, 15a, 15c]
[12:54:05] <ggm> [slide 23 list of medium/low desireables]
[12:54:16] <ggm> long list. ordered with med above low.
[12:54:35] <ggm> Steve Crocker 4 issues.
[12:56:09] <ggm> comment about trade-offs in security problems. my view is, not everyone concerned with NSEC problem. are people who care a lot, requirement is there, but not everyone is going to say 'important to us' may be happy with current spec. those who are concerned, may not have same consideration about online keys. have split among zone owners, care/dont-care about both NSEC, zonewalk and online keys. hope is, those who care a lot, typically large CCtld, care about privacy, in good shape to put keys online with hardware. point is, tradeoffs,
[12:56:23] <ggm> Olaf want to defer to end of presentation.
[12:56:42] <ggm> Steve point 2. in text, language to say, range for NSEC has to match
[12:56:46] <ggm> Olaf will be covered
[12:57:09] <ggm> Steve point 3 Q. raise NSEC++ should apply to zones, if poss. do we have any examples of where not apply?
[12:57:11] <ggm> Olaf cover later
[12:57:38] <ggm> Steve point 4. DNS purity: john ashcroft is available ...
[12:57:40] --- Jim Galvin has left
[12:58:02] <ggm> Rip continues.
[12:58:13] <ggm> [slide 25 other notes]
[12:58:38] <ggm> preventing enumeration of RR types, could be done, hugely expensive, not requirement in this doc. not reviewed.
[12:58:43] <ggm> [slide 26 way ahead]
[12:58:57] <ggm> will update draft to reflect this matrix/plan if people ok. next step, ID with weightings. end.
[12:59:18] <ggm> Mark Andrews DNSSECbis doesn't cover RCODE, some solution spaces for this do.
[12:59:22] <ggm> Olafur noted.
[12:59:33] <ggm> Olaf. strawman/proposed way forward.
[13:00:03] <ggm> would like to capture whats in slides, put out as ID, ask for consent on this. voice objections, but if can live with, please don't debate.
[13:00:42] <ggm> Did scan of solution space. covers what we are aware of. Mark said "solutions to cover RCODE" not in this list maybe.
[13:01:03] <ggm> two branches. either dynamic answer, or do hash based NSEC++ approach.
[13:01:17] <ggm> (hash is precalc, do not need online key)
[13:01:47] --- vlevigneron has joined
[13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it on the fly. minimally cover. idea has been posted to ML. not in archive. use NSEC mechanism, good things, can use current resolvers to validate. would mean can deploy DNSSECbis without enumeration properties, if can implement this in server.
[13:02:50] <ggm> Another is 'MagicType' -protocol change. Q name for thing with no RR, send back answer with 'magic type' and tells resolver 'do nothing here' -fine for upgraded resolver.
[13:02:58] <ggm> Roy. protocol change, WHAT protocol change?
[13:03:02] <ggm> Olaf need new validator.
[13:03:12] <ggm> Olafur everything needs to be updated.
[13:04:16] <ggm> on hash based, precalc side, can do *.no opt-in forbid them. or with optin, (4 way choice, its a matrix of wildcard and opt-in yes/no)
[13:04:48] <johani> FYI: I just put up the epsilon draft at http://www.axfr.net/~johani/draft-weiler-dnssec-qname-epsilon-00.txt if anyone is interested.
[13:05:01] <Suz> thanks
[13:05:19] <jas> fwiw, dynamic NSEC violate DNSSECbis section 2.3 of -protocols.
[13:05:21] <ggm> some of these require online key. some require protocol change, some prevent universal signing.
[13:05:50] <ggm> if labels close to 255, cannot generate signed outcome and so cannot do signing for them.
[13:06:14] <ggm> Olaf shows matrix of outcomes from solutions. you need to see his slideset.
[13:06:36] <ggm> Olafur not sure if any names in use today which will be affected.
[13:07:05] <ggm> if allow for online keying, can deploy 'epsilon' today. needs review, thoughts, but can do deployment today without much hurt.
[13:07:20] <ggm> the other things need engineering. Qs to answer, how to deal with wildcards, delegation points, ugly stuff.
[13:07:54] <ggm> Proposed way forward: fast-track epsilon in this group, review, try to see if will work, publish asap. so that things can be deployed today. in same time, continue on other solutions, without makeing choices.
[13:09:00] <ggm> Goal is to have one DNSSECter. one mechanism, in addition to current NSEC. do not 5 solutions. may have options to tweak, but we're not there yet.
[13:09:21] <ggm> Mark A. NSEC+/-<e> doesn't handle 2octet remaining issue. enumerating there is non-issue, but ..
[13:09:44] <ggm> Ben think that is wrong. have draft. also universal signing only problem if you think hash is name. if other, then can do it with hashes.
[13:09:59] <ggm> Roy many of the issues with universal signing are likely to happen in deep zones, with wildcards
[13:10:08] <ggm> (sorry that was Olafur)
[13:10:23] <ggm> Roy. long name, multiple labels can sign DNAMES CNAMES etc.
[13:10:49] <ggm> Olaf moving into solution spaces. ugly corner cases. may not need to corner. Q is, pose to room, does this way forward work?
[13:11:18] <ggm> Steve C. two things. term 'no universal signing' is categorical means 'fringe' zones displaced. can you characterize which zones, approx or exact how big it is?
[13:11:19] --- ed has left: Disconnected
[13:12:05] <ggm> if go back one slide, today, can do online key. magictype looks to be worse. requires key AND change. not evident whats compelling about it. in the choice posed, that vs proto changes to support hash, choose NSEC+/i<e> and proto for hash, removes choice.
[13:12:23] <ggm> Olaf reason to keep magic type, is to prevent universal signing loss. if more important than hash..
[13:12:29] <ggm> Olafur with magictype can throw away NSEC.
[13:12:55] <ggm> Rob A. magic type, bad name, used on whiteboard. signed on the fly neg cache entry. cant do that with SIG0.
[13:13:10] <ggm> because no NSEC< packets get smaller. this is good.
[13:13:23] --- Jim Galvin has joined
[13:13:38] <ggm> other thing. universal signing. two problem cases. Ben says, treat names of recs as names. namelength issue. some proposals say 'to hell with wildcards' so cant sign zones with wildcards.
[13:13:58] <ggm> Olafur wildcard makes long names more likely.
[13:14:09] <ggm> MarkA magic type has benefits otherwise
[13:14:38] <ggm> Olaf [humm gives good room indication to proceed]
[13:14:52] <ggm> Olaf now doing key management issues., trust anchors.
[13:15:12] <ggm> Johan Ihren. threshold based trust update
[13:15:40] <ggm> old personal submission at San Diego, auto rollover mechanism with zero protocol changes.
[13:16:06] <ggm> had sig threshold.
[13:16:20] <ggm> was adopted, new doc changed name. took opportunity to fix bugs.
[13:16:49] <ggm> may be IPR issue. patent may cover this, unable to find. know company, believe friendly.
[13:17:34] <ggm> changes: simplified definitions of threshold params. "at least M out of N possible sigs must validate"
[13:17:37] <ggm> documented state machine
[13:18:24] <ggm> slide of diagram of states.
[13:20:05] <ggm> bad state can come from being offline for a long time. (exceeding life of all signatures. eg box on shelf as cold spare)
[13:21:11] <ggm> priming not covered by draft.
[13:22:32] <ggm> fixed replay attack, by introducing time based sequencing logic
[13:22:33] --- mstjohns has left: Disconnected
[13:23:03] --- Jim Galvin has left: Replaced by new connection
[13:23:38] <ggm> Mike St Johns
[13:23:43] <ggm> Trust anchor update.
[13:23:58] <ggm> presentation given at last IETF.
[13:24:26] <ggm> going to have large deployed base of clients/recursive servers with trust anchors
[13:24:56] <ggm> hopefully at least 2 anchors at any given trust point, one active, one in reserve.
[13:25:08] <ggm> design goals, make it work with at least one non-compromised key.
[13:25:23] <ggm> minimize other attacks
[13:25:59] <ggm> trust model chains from known good key, signs new key, then can trust new key. not quite that simple. timing, verification etc
[13:26:06] <ggm> state machine not changed since last time.
[13:28:04] <ggm> examples of trust anchor changes also not changed
[13:28:51] <ggm> major change between versions, is addition of timer mechanism. before used assume client did occasional queries to check. this time force client to refresh, on boot, or query, or if not seen for a while minimize problems when client goes away, changes online, client back and universe has moved.
[13:29:26] <ggm> possibilities on how to get back with state offline 2years, world shift. haven't written this down yet. eg tarball of new state, journalling over time. need analysis
[13:29:45] <ggm> checks draft have been read [good readership]
[13:30:01] <ggm> 2 Qs for group. make sense to persue? client updates inband?
[13:30:10] <ggm> Olafur, Q is premature.
[13:30:49] <ggm> Olafur: ask doc editors, Johan first, what shape doc is in? complete? needs more revisions? how long to address IPR issue?
[13:31:47] <ggm> Johan pretty complete for simple part. weeks.
[13:32:25] <ggm> Mike. short answer, good shape, major thing is tuning params. complex interactions between timers here, DNS/DNSSEC work. need to be safe.
[13:33:19] <ggm> Olafur solicit Security AD feedback, ask room/wg if they want to proceed with both/either/none. feedback requested soon.
[13:33:36] <ggm> when eds say ready, lets consider.
[13:34:09] <ggm> ben laurie on key distribution
[13:34:10] --- mike has left: Disconnected.
[13:34:21] <ggm> Olaf. dropping WG administrivia. may run into break.
[13:34:58] <ggm> Ben. islands of trust issues, some people don't like single auth. inband stuff is tricky. lots of keys, lots of data
[13:35:52] <ggm> mechanism is cross-signing scheme. start with one, fetch more. can recurse or stop
[13:36:53] <ggm> Olaf. read, post comments.
[13:37:02] <ggm> will ask auth if wants WG item, will take to list
[13:37:54] <ggm> Sam . bens draft makes no changes to DNS. may be better in DNSop. but all better of with single home for the work.
[13:38:01] <ggm> Olaf charter issues will be discussed on list
[13:38:02] --- ed has joined
[13:38:09] <ggm> Olaf cross fertilization issues
[13:38:50] --- ed has left
[13:40:14] <ggm> Ed Snell, ind. submission on web service discovery using DNS. -things used via WSDL.
[13:42:38] <ggm> ben. -have to know DNS name of thing to look up in the first place, why does this belong in DNS? why not have WKS providing service at this address?
[13:43:47] <ggm> uddi servers not always at same location. identified by QNAME. can have URL if service moves, learn to deal with it.
[13:44:16] --- mstjohns has joined
[13:44:29] <ggm> Bill M. NAPTR springs to mind. don't need new ones. DNS is not the only bootstrapping engine. can do it easier using BGP [laughter]
[13:45:14] <ggm> issues concerned about NAPTR complexity
[13:46:02] <ggm> want somewhat meaningful names
[13:46:53] <ggm> Paf can be done via NAPTR
[13:46:59] <ggm> Ed want feedback.
[13:47:17] <ggm> Olafur feedback to authors
[13:48:04] <ggm> Patrik mention the IAB document on DNS choices. talk about design goal issues. why NAPTR help you, what are the caveats.
[13:49:19] <ggm> Alain Durand process clarification. how to get discussion on new RR? this group?
[13:49:39] <ggm> Olaf. expertise group on DNS, provide advice. new RR proposed, will look at it, not going to look at the proposal per se.
[13:50:38] <ggm> Thomas Narten. to define new RR two aspects - makes sense from DNS perspective, - does it have something meaningful recuser is going to use? one is DNS perspective, other is specific to context. IANA considerations, may need IESG approval. will ask if WG have looked at it. some review, not all work done here.
[13:50:58] <ggm> Alain. in another proposal need new RR. should have separate draft to discuss here or do in same doc?
[13:51:08] <ggm> Olafur, we look at the section of the doc, not the rest of it.
[13:51:49] --- miek has left
[13:51:56] <ggm> Stephane Bortzmeyer, SPF RR for DNS.
[13:52:17] <ggm> protocol needs data distributed. wants to use DNS. purpose is to authenticate email sender.
[13:52:48] <ggm> currently data in TXT record. most domain manager cannot edit arbitrary record to DNS. typically only have limited choices in UI
[13:52:59] --- pawal has left: Disconnected
[13:53:01] <ggm> many other proposals use TXT, senderID, domain keys do the same.
[13:53:39] <ggm> we try to be nice. proposal to add new RRtype for SPF. format is same as TXT from 1035. need to keep TXT compatible format for backwards compat.
[13:53:49] <ggm> SPF doesnt use XML, uses small language. just need typecode
[13:54:05] --- amarine has left
[13:54:09] <ggm> SPF is already deployed, have SPF recs. coexistence of old TXT, new SPF rec.
[13:54:19] <ggm> FTC summit, PHB said 'will not happen'
[13:54:38] <bruce2> phb?
[13:54:42] <ggm> 3 free impls, 200,000 domains
[13:54:55] <ggm> Phil Hallam Baker or Pointy Headed Bastard (dilbert) but in this context, Phil
[13:55:16] <bruce2> ta.
[13:55:57] <ggm> can need big TXT records.
[13:56:03] <ggm> fits in typical DNS record
[13:56:20] <ggm> Sam. apps query for both?
[13:56:31] --- Hollenbeck has left
[13:56:32] <ggm> Stephane Yes, its a SHOULD. in debate in SPF community
[13:57:07] <ggm> Like to see text as 'check SPF first, then if no data check TXT'
[13:57:18] <ggm> Stephane broken resolver, unknown RRtype.
[13:57:30] <ggm> MarkA nodata - can get answer back saying doesn't exist
[13:58:52] --- nov has left
[13:59:35] <ggm> Peter Koch. spoke about fantasy. great! cited somebody claimed deployment figures on TXT rec. I have done survey of ccTLD, (de) 8,000,000 domain names, figures seem different. be very careful claiming deployment numbers.
[13:59:55] --- edinburgh_craig has left: Disconnected
[14:00:03] <ggm> urge you not to stick with TXT. don't mess with TXT, leave alone. early adopters, can be assumed to migrate, provisioning issue is non issue
[14:00:25] <bruce2> [migrating later is always a worrying issue]
[14:00:53] <ggm> Rob A txt specification fine. implementations sucked.
[14:03:05] --- dblacka has left: Disconnected
[14:03:26] <ggm> OIafur. discuss on list. avoid issues of SPF, focus on DNS.
[14:03:26] --- Mark has left: Disconnected
[14:03:35] --- yone has left
[14:03:35] --- rpayne422 has left: Disconnected
[14:03:36] <ggm> Olaf. done.
[14:03:43] --- robertml has left: Logged out
[14:04:19] --- ogud has left: Disconnected.
[14:04:22] --- Suz has left
[14:04:30] --- admcd has left
[14:05:02] --- jas has left
[14:05:28] --- jaap has left: Disconnected
[14:06:23] --- remowilliams has left: Disconnected
[14:06:49] --- johani has left: Disconnected
[14:08:46] --- bruce2 has left
[14:09:38] --- raj has left: Disconnected
[14:10:02] --- mstjohns has left: Disconnected
[14:12:35] --- marka-isc has left
[14:15:37] --- wes has left: Disconnected
[14:15:50] --- ggm has left: Disconnected
[14:16:28] --- vlevigneron has left: Replaced by new connection
[14:23:18] --- ripple has left: Disconnected
[14:25:05] --- peterd has left: Disconnected
[14:25:20] --- tskj has left: Disconnected
[14:37:25] --- marka-isc has joined
[15:05:25] --- marka-isc has left
[20:05:17] --- ogud has joined
[20:06:19] --- ogud has left: Disconnected.
[20:06:55] --- ogud has joined
[20:30:40] --- ogud has left: Disconnected.
[20:37:41] --- ogud has joined
[20:42:53] --- ogud has left
[20:51:57] --- ogud has joined
[21:25:25] --- ogud has left
[22:09:38] --- orange has joined
[22:10:03] --- orange has left