[07:58:26] --- robp has joined
[08:02:50] --- Rob has joined
[08:02:57] --- Rob has left: Disconnected
[10:19:42] --- raj has joined
[10:29:18] --- ggm has joined
[10:32:32] --- wesleygriffin has joined
[10:36:16] --- raj has left
[10:42:58] --- Olaf has joined
[10:55:16] --- mstjohns has joined
[10:55:43] <ggm> 5 minute warning. principals to the front of stage, chorus line girls are now adjusting their head-dresses..
[10:56:33] <mstjohns> having some network problems in the room... may not have a jabber scribe this time..
[10:56:34] --- frodek has joined
[10:57:49] <ggm> I volunteered to scribe.
[10:57:54] <ggm> jabberscribe that is
[10:57:59] <mstjohns> ah....
[10:58:40] --- rip-l has joined
[10:59:05] --- mrichardson has joined
[10:59:08] <mrichardson> hi.
[10:59:25] --- FDupont has joined
[10:59:29] <mrichardson> network came back just now. wonder what happened.
[10:59:55] --- weiler has joined
[10:59:59] --- fneves has joined
[11:02:03] --- marka-isc has joined
[11:02:30] --- jinmei has joined
[11:02:33] --- marka-isc has left: Lost connection
[11:02:33] --- jinmei has left: Lost connection
[11:02:54] --- mike has joined
[11:03:04] --- oatwillie has joined
[11:03:06] <ggm> we're off.
[11:03:13] --- suz has joined
[11:03:13] --- suz has left: Lost connection
[11:03:30] <ggm> [Administrivia..]
[11:04:00] --- suresh has joined
[11:04:03] --- marka-isc has joined
[11:04:03] --- marka-isc has left: Lost connection
[11:05:03] <rip-l> Is anyone else trying to listen to the uoregon.edu 64kbps MP3 audiostream? Is anyone else actually hearing anything?
[11:05:07] --- suz has joined
[11:05:34] <ggm> mdns got significant comments at wglc. pushed back to WG. V05 incorperated. going over comments.
[11:05:54] <suresh> I am ... audio is pretty clear
[11:05:58] <ggm> 2 drafts in RFC-Editor Q. insensitive, and rfc2538bis
[11:06:14] --- Peter Koch has joined
[11:06:14] --- mo7sen has joined
[11:06:15] --- wesleygriffin has left: Disconnected
[11:06:39] --- joshlitt has joined
[11:07:01] <ggm> last call completed on nsid, 2536bis-dsa & 2539bis-dhk
[11:07:13] <ggm> no drafts in last calls.
[11:07:18] <ggm> yay!
[11:07:45] <weiler> IMHO, if 2536/9 get advanced, an appeal would be in order
[11:07:52] <ggm> axfr-clarify got 'lost' . significant comments at WGLC
[11:07:56] <weiler> there's no record of meaningful WG review of the docs.
[11:08:43] <ggm> 3 drafts waiting for last call: dnssec-trans, dnssec-experiments & ecc-key
[11:09:06] <ggm> trans is ready (according to peter K) so will progress asap
[11:09:31] <ggm> sam weiler comments at mike as per his jabber..
[11:09:46] <ggm> Olaf says 'no comments to list' -none of any kind.
[11:09:49] <ggm> Sam: then why advance?
[11:09:58] <ggm> Olaf: used nothing as default. no complaints.
[11:10:05] <ggm> Sam: I complained about default
[11:10:24] <ggm> Olaf, we adopted as WG doc. assumption people spend work on it. hence the default
[11:10:30] --- rstory has joined
[11:10:31] <ggm> Sam false Assumption
[11:10:38] <ggm> Olafur. we think default is reasonable.
[11:10:52] <oatwillie> and the reason for an appeal would be ...
[11:11:06] <ggm> Tom Narten. agree with Sam. valid Q. fact is, if nobody reviewed, and think is good.. Call for evidence.. [2-3 hands up]
[11:11:27] <ggm> Olaf problem often seen in this group
[11:11:36] <ggm> Narten Solution is NOT to push through by default
[11:11:50] <ggm> Sam maybe default of 'remove from WG list' will make people move on things.
[11:11:52] --- rstory has left
[11:11:59] <ggm> Olaf. Don Eastlake will speak on this
[11:12:06] <ggm> Sam no issues with content of doc.
[11:12:24] <ggm> [back to Agenda for now]
[11:12:53] <ggm> ongoing work: bis-updates, 2929bis, signed-nonexistence-reqts, nsec3 are work in-hand to be discussed today
[11:14:11] <rip-l> I'm here...it's not ready for last call..
[11:14:20] <rip-l> (Requirements doc).
[11:14:35] <rip-l> It needs WG review, plus some minor tweaks from me.
[11:14:55] <ggm> Reports: Don Eastlake on 2929bis
[11:15:16] --- royarends has joined
[11:15:49] <ggm> ecc-key draft clarified to cover SHA-1. needs more feedback. -esp. from implementors
[11:16:13] --- dcrocker has joined
[11:16:20] <ggm> updates to remove sig/key dependency. update RFC references.
[11:16:21] --- marka-isc has joined
[11:16:50] <ggm> made it more type-agnostic, reference newer RFCs. hardly any changes. no rdata structure change at all
[11:17:24] <ggm> ECC comments. NSA re-licencing some patents in this area
[11:17:30] <mrichardson> NSA relicensing some stuff.
[11:17:44] <mrichardson> this seems weird that one can relicense stuff for specific numbers....
[11:18:07] <ggm> Olafur: may get some interop issues if field-use is semi-random. does DNS need more restricted key format, known to be implemented/interoperable?
[11:18:18] <ggm> Don: could be. need ECC implementors feedback on this
[11:18:37] <ggm> [I dibs on number 42]
[11:18:44] <ggm> Olaf calls for people who have read the draft.
[11:18:54] <ggm> [handful]
[11:19:08] <ggm> [of handful, how many implementors? [one] just a datapoint]
[11:19:15] <ggm> Don one is better than zero [laughter]
[11:19:17] <rip-l> How many people actually read the draft *and* had a clue what they were reading?
[11:19:24] <ggm> No comments on ECC draft from floor.
[11:19:40] <ggm> now 2929bis.
[11:20:18] <ggm> types & classes stuff. some values requring standard action, registry functions,
[11:20:34] <ggm> feeling that 'too hard' for type codes. - leads to overloading of TXT.
[11:20:59] <ggm> 00 draft went for a liberalized allocation process to prempt codes before standards locked in.
[11:21:10] <ggm> discussed at paris, some dissent. 01 produced (current draft)
[11:21:47] --- suz has left
[11:21:48] <ggm> effect is to liberalize 2929. define own policy -replace IETF consensus with DNS type allocation policy for RR type codes
[11:22:23] <ggm> Opcodes still require IETF standards action, as per 4020
[11:22:38] <ggm> there are other more minor changes in the draft (eg RFC ref updates)
[11:22:51] <ggm> so the 01 now has big hunk of typecodes needing expert review
[11:23:10] --- wrs1864 has joined
[11:23:17] <ggm> -3 weeks on namedroppers list, must be complete to move on. incomplete welcome for comments
[11:23:35] <ggm> this is about 1/2 th codes. other half subject to IETF process
[11:23:49] <ggm> template covers the why/whatfor/special-issues stuff
[11:24:10] <ggm> big change from 00 state based on Paris comments
[11:24:14] <ggm> wants feedback on this
[11:24:23] <ggm> Rob at mike: still have 'required only' rcodes?
[11:24:26] <ggm> Don Yes.
[11:24:34] <ggm> Rob please remove. having codes not understood is bad idea
[11:25:26] <ggm> Tom Narten. missing in doc, comments made to Olaf y'day. issue with this group: whats the crtieria for reviewing? how to push back? eg if rset use is silly. need to document the criteria. intend to write something up as proposal to ML.
[11:25:26] --- mo7sen has left: Disconnected
[11:25:32] <ggm> Don good idea. love to have this guidance.
[11:25:54] <ggm> Tom expert review is good. got bad rap in some circles. experts need to be answerable to the community.
[11:26:27] <ggm> Tom not supposed to 'make the decision' without accountability, but help WG to make decision
[11:27:45] --- mstjohns has left: Disconnected
[11:28:32] --- suresh has left: Disconnected
[11:28:33] --- mrichardson has left: Disconnected
[11:28:33] --- ggm has left: Disconnected
[11:28:33] --- dcrocker has left: Disconnected
[11:28:33] --- mike has left: Disconnected
[11:28:33] --- frodek has left: Disconnected
[11:28:33] --- royarends has left: Disconnected
[11:28:33] --- Peter Koch has left: Disconnected
[11:28:33] --- joshlitt has left: Disconnected
[11:28:33] --- wrs1864 has left: Disconnected
[11:30:06] --- ggm has joined
[11:30:27] <ggm> sorry. lost my jabber binding there. Don finished.
[11:30:31] <ggm> We're on a Mark Andrews doc.
[11:30:36] <ggm> auth discovery
[11:30:49] <ggm> needs review, has issues. large number of readers interested
[11:31:21] --- suresh has joined
[11:31:38] <ggm> Olaf. Trust Anchor discussion moved to end. (agenda change) so NSEC3 now under discussion, Ben laurie to the plate
[11:32:02] <ggm> Ben. covering issues still open in NSEC3, review whats been closed. please let us know if we're missing anything.
[11:32:43] <ggm> Issue #1. signalling. should NSEC3 be signalled so unaware resolvers see is as 'unsecure' rather than 'bogus' ?
[11:32:57] <ggm> no strong opinion clear yet. up to WG to decide
[11:33:18] <ggm> Issue #2 Transition
[11:33:31] <ggm> does NSEC->NSEC3 require period of insecurity? consensus is its OK
[11:34:05] <ggm> Issue 3. minor issue with base 32 encoding, different sort order to binary representation. painful. fixed by switching to 2932 base32 encoding, same sort order bin/textual
[11:34:08] --- dcrocker has joined
[11:34:35] <ggm> Issue 4 hashes make owner names in zone. problem or not? nobody clear this is a problem. we THINk consensus is no, not a problem. disagree?
[11:34:41] <ggm> Peter K. already said I disagree on ML.
[11:35:15] <ggm> we don't know yet.
[11:35:24] <ggm> Dangerous to just neglect the problem
[11:35:53] <ggm> Ben what do you propose we do? why stall if no clear indication?
[11:36:09] <ggm> Peter but we got here (NSEC->NSEC3) because of unknown problems at the time being found later on
[11:36:25] <ggm> More research needed.
[11:36:30] <ggm> Ben so issue not closed, needs more discussion?
[11:36:32] <ggm> Peter yes
[11:36:32] --- mjo has joined
[11:36:54] --- oatwillie has left: Disconnected
[11:36:57] <ggm> Russ Mundy. Q for peter, comment to comment.
[11:37:00] --- mstjohns has joined
[11:37:05] <ggm> didn't grasp whats being said about WHY a problem in the future.
[11:37:48] <ggm> I wondered if others had same problem understanding. general concept, if we are not willing to say we are going to make a decision one way or the other about potential problems, we can't find strong basis for, will be paralyzed forever.
[11:37:49] --- wrs1864 has joined
[11:38:13] <ggm> Suggest understandable problem identification, or flag as 'could bite in future' but move forward, knowing they exist
[11:38:20] --- FDupont has left: Disconnected
[11:38:49] <ggm> Olafur. try to clarify. issue is: NSEC covers all names in zone. NSEC3, suddenly see names in zone NOT in NSEC. classifyable as 2nd class names. not in NSEC chain per se.
[11:38:54] --- mjo has left
[11:39:12] <ggm> So the issue here is, 'do experiments' see if turns out to be issue, at least until experimental evidence one wya or the other.
[11:40:15] <ggm> Olaf won't progress to IESG until engineering workshop.
[11:40:23] <ggm> Agreed we need to see code working in a lab.
[11:40:38] <ggm> MarkA. issue #1. object to having flag day to NSEC3
[11:40:44] --- dcrocker has left
[11:40:52] <ggm> [ggm offline for a bit..]
[11:41:05] <mstjohns> [stjohns will pick up temp]
[11:41:20] --- mrichardson has joined
[11:41:22] <mstjohns> ben - if we're going to do singaling, need to decide how.
[11:41:26] --- suz has joined
[11:41:55] <mstjohns> ed lewis at the mike: Ed won't consider closed (issue 4) until see it working in operation
[11:41:55] --- suz has left: Lost connection
[11:41:57] <mrichardson> is the issue with new names in the zone a human problem or a technical problem?
[11:42:18] <mrichardson> i.e. is the issue that people might object to these new names, or that this may in fact confuse NSEC3 (or NSEC) processing.
[11:42:35] --- suz has joined
[11:42:47] <mstjohns> sam weiler: we're breaking our theoretical data model. Could be future problem.
[11:43:18] <mstjohns> ben (issue 5) what happens if hash and real name collide. no problem with having other rr types where there's an nsect 3 - probably closed.
[11:44:11] <mstjohns> Rob Austein: 3/4 convinced that new label type required.
[11:44:44] <mstjohns> Rob Austein: Probaly not an issue for non-dnssec resolvers
[11:44:59] <mrichardson> we did extensive testing to make sure that DNSSEC stuff would get through DNS-unaware and DNSSEC-rfc2535 aware stuff.
[11:45:19] <mrichardson> we stubbed our toes, and did TKR.
[11:45:22] <mstjohns> Paul Vixie: Wanted to clarify: all problems in dnssec derive from including new metadata about itself (DNS).
[11:45:29] <mrichardson> er, TCR.
[11:46:09] <mstjohns> [stjohns ending]
[11:46:09] <ggm> [ggm back]
[11:46:29] <ggm> separate label type prevents this mixing with additional data.
[11:46:31] <weiler> A NEW CLASS!
[11:46:55] <ggm> we're going to discover this is much harder than slide implies
[11:47:16] <ggm> Ben: people happy to wait for some testing before we really decide? anyone disagree?
[11:47:23] <ggm> Olafur. 3 impls ready to test.
[11:47:28] <ggm> ben nearly. within a month or so
[11:47:40] <ggm> Olafur. then have bake-off. get info made public.
[11:47:54] <ggm> Russ: have approx. time for bake-off?
[11:48:08] <ggm> Ben: in the next month or so. don't know when planning to do.
[11:48:20] <ggm> Issue 6
[11:48:39] <ggm> DoS attacks on resolvers: high numbers of iterations of the hash.
[11:48:49] <ggm> propose to allow resolvers to specify upper limit. bogus if exceeded
[11:48:56] <ggm> Olafur as floor person.
[11:49:10] <ggm> can we get rid of iterations? just salt?
[11:49:30] <ggm> Ben iterations designed to increase cost of dictionary. salt is to prevent pre-computed dictionary attacks. different attacks.
[11:49:38] <ggm> one is cost, one is how often to make dictionary. not same
[11:49:54] <ggm> Olafur. know that. but if salt good enough for threat models being seen, driving up cost..
[11:49:57] --- joshlitt has joined
[11:50:25] <ggm> Ben try to make it as hard to walk in dnssec as in dns. single iteration of hash is way way easier than is repeated iterations. without iterations, not achieving requirement
[11:50:48] <ggm> Olaf. if allow resolver to set upper limit, some will set low, some high. operational nightmare. for some part of the world, zone will resolve, for other part, bogus.
[11:51:01] <ggm> ben limit should be high, compared to real-world expected
[11:51:27] <ggm> don't want to fix, changes with time and hash alg. set in ID, invalid in future. should be recommendation, but not in draft
[11:51:32] <ggm> Mike St Johns groans...
[11:52:01] <ggm> dont understand objection to number in document.
[11:52:18] <ggm> re-spec per hash alg. new standard anyways. put something in the doc. be nice to implementors. [heckle: users]
[11:52:37] <ggm> seriously. no reason not to put number in here. wrong too high is cool. wrong too low is security issue, willbe blocked in review
[11:52:53] <ggm> this has to be common number. not configurable
[11:53:09] <ggm> Ben. we'll do it if the WG feels strongly
[11:53:27] <ggm> Schtrecter: if configurable, parent zone specify limits, max, min for child? [groans.... NO from floor]
[11:53:45] <ggm> Ben resolver should choose high number, server unlikely to exceed.
[11:54:00] --- frodek has joined
[11:54:04] <ggm> Olaf: big caches. will have to do work.
[11:54:17] <ggm> Sam. if they elect not to do validation, don't have to do work.
[11:54:24] <ggm> Olaf its a might: might-not.
[11:54:42] --- mrichardson has left: Disconnected
[11:54:48] --- suz has left
[11:55:07] --- suz has joined
[11:55:28] <ggm> Sam. MstJ said iterations per alg specified.
[11:55:32] <ggm> Ben ok.
[11:55:37] <ggm> Mike in violet agreement
[11:55:56] <ggm> Issue 7. secondaries, how do they know the NSEC3 params?
[11:56:15] <mstjohns> MstJ said "max iterations" per alg. Still settable by zone to lower number...
[11:56:15] <ggm> inheritance from apex. in this version of the draft
[11:56:47] <ggm> Issue 8. need more info to explain why. h
[11:57:05] <ggm> Issue 9/. fix bitcount to align the hash alg ids
[11:57:19] <ggm> Issue tracker, nsec3.nominet.org.uk. not ready yet but will announce
[11:57:56] <ggm> Sam: issue 9. could get rid of it in field, use the DS rec value from parent
[11:58:21] <ggm> MikeStJ using multiple hash algs for zone?
[11:58:31] <ggm> Sam would have multiple NSEC3 chains
[11:58:46] <ggm> seeking to minimize parameters.
[11:59:49] <ggm> Olaf. next stuff: Interop Testing Reports
[12:00:19] <ggm> Speaker not present. skipping.
[12:00:23] <ggm> Trust Anchor Management.
[12:00:31] <ggm> space growing with drafts
[12:00:49] --- Peter Koch has joined
[12:01:13] <ggm> not seeing review except from doc authors/editors. urge WG to pay attention. important stuff
[12:01:48] <ggm> new work being proposed, will be presented by authors.
[12:02:12] <ggm> Johan Ihren not here to speak to draft. Bill to front
[12:02:25] <ggm> Olaf. co-author but keeping neutral on this
[12:02:36] <ggm> Bill
[12:02:57] <ggm> Update is boilerplate to refresh, available for consideration. implementation being built
[12:03:29] <ggm> some IPR claims against both this and timers draft. working with lawyers, told can do proof of concept even with IPR claim.
[12:03:59] <ggm> Testing expected, results to be given to people who wont suffer IPR issues
[12:04:03] <ggm> MikeStJ
[12:04:21] <ggm> [Bill lost his bet not to speak at mike but claims its a fix since he was made to do it]
[12:04:44] <ggm> working on code for timers model. using DNS java. straightforward to impl
[12:04:57] <ggm> Q asked about turning on and off. will discuss at later.
[12:05:37] <ggm> Thierry Moreuau to present on TAKREM
[12:06:39] <ggm> fortuitous invention.
[12:07:47] <ggm> reviews why rollover of anchor: catastrophic failure issues in pvt key compromise, master key compromise and dormant key compromise
[12:12:40] <weiler> he's waving props around.
[12:12:41] <ggm> proposes split key architecture, with pre-computed keys
[12:13:10] --- suz has left
[12:13:52] --- dnsext has joined
[12:14:38] --- dnsext has left: Disconnected
[12:15:30] --- suz has joined
[12:15:43] --- dnsext has joined
[12:16:53] <ggm> going through rollover procedures
[12:18:05] --- raj has joined
[12:18:24] --- raj has left: Disconnected
[12:20:25] --- mrichardson has joined
[12:20:34] <ggm> properties: simple scheme. auditable. emergency rollover same as scheduled, except for key revokation. -resolvers can be offline during rollover. transition from island to connected state is simple.
[12:20:37] <ggm> Ben.
[12:21:09] <ggm> Emergency rollover doesn't deal with key revokation, then don't understand the point. other mechanism unavoidably needed so why not use other mechanism anyway?
[12:22:00] <ggm> wants to bring TAKREM into dnssec.
[12:22:16] <weiler> dnsext
[12:22:35] --- raj has joined
[12:22:36] --- FDupont has joined
[12:23:20] --- raj has left: Disconnected
[12:23:26] <ggm> exsqueeze me. s/sec/ext/g
[12:24:14] --- raj has joined
[12:24:29] --- fneves has left
[12:24:29] --- fneves has joined
[12:24:31] --- geoff has joined
[12:25:59] <ggm> Bill. patent-pending issues. licencing being considered. can you reconcile? are the IPR issues withdrawn?
[12:26:35] <ggm> Thierry no. the IPR issue is still on the table
[12:26:54] <ggm> MikeStJ. key validity seems to span forever, previous keys aren't revoked.
[12:27:02] <ggm> Thierry on expiry of ttl/age.
[12:27:23] <ggm> Olafur: no lifetime on keys, just on sigs.
[12:27:29] <ggm> Thierry then have to look at it
[12:27:58] --- geoff has left
[12:28:31] <ggm> Steve Crocker. IPR. confused. had the impression it was a zero-cost availability for all implementations. whats your position on this?
[12:29:44] <ggm> Vixie. Steve helped negotiate the DNSSAFE deal. enabled ISC to publish open-source impl of DNSSEC. difficulty of the 'reasonable' issue. IPR claims will stand in the way. We need F/OSS code to make it.
[12:29:51] <ggm> Olaf. requirements are .. ?
[12:31:31] <ggm> Steve. can have discussion about technologies, independent of the IPR, or we can get the IPR squared away ahead of time. depends on constraints. far easier if tech available, can have free/open impls and get on with the testing & detailed analysis.
[12:31:37] --- kivinen has joined
[12:31:44] <ggm> Thierry. licence for GPL impl already available.
[12:31:50] <mstjohns> From rfc 3979 An IETF consensus has developed that no mandatory-to-implement security technology can be specified in an IETF specification unless it has no known IPR claims against it or a royalty-free license is available to implementers of the specification unless there is a very good reason to do so.
[12:32:11] <ggm> Thierry available to talk.
[12:32:23] <ggm> Ben. free licence for GPL doesn't help because the s/w of interest is not GPL
[12:32:59] <ggm> Tom Narten. tough topic. caution the idea you can deal with IPR up front or at-end. neither works that well. need both. but cannot just plough through
[12:33:12] --- dblacka has joined
[12:33:23] <ggm> if IPR is obstacle, can make signal 'not fruitful' but these are tough decisions, depends on licencing terms, who are early adopters etc
[12:33:49] <ggm> Thierry. more info on the requirements spec would be useful. set by group.
[12:33:58] <ggm> Olaf licencing requirements?
[12:34:08] <ggm> Thierry no trust anchor key requirements. clarify mandatory or optional
[12:34:11] --- maxwell has joined
[12:34:21] --- weiler has left
[12:34:58] --- weiler has joined
[12:36:17] <ggm> Ben Laurie on trust anchor distribution
[12:37:23] <ggm> idea is that island of trust will produce toor ca key. big, longlived, infrequently used. will sign secure entrypoint keys for zone, sign other cas, to be rolled more frequently. used to sign toor ca keys for other islands of trust
[12:37:51] <ggm> nice diagram with colours. ironically the UK is green (since its a wet, drab grey in reality) and germany is red (which it hasn't been since 1923)
[12:38:10] <ggm> both wind up blue. which is true, post the thatcher revolution
[12:38:21] <ggm> talking about cross-signing, web of trust
[12:38:56] <ggm> originally proposed for the non-root signed state but can be used to do rollover even with a signed root
[12:39:04] <ggm> only proposal with no IPR
[12:39:19] <ggm> Bill goes to mike
[12:39:30] <ggm> nobody made him. so he lost the bet doubly
[12:39:32] <ggm> URL chains.
[12:39:41] <ggm> Ben with Sigs.
[12:39:52] <ggm> Bill transport?
[12:39:54] <ggm> HTTP
[12:40:36] <ggm> Bill considering the old e2e internet, nice. but now its walled garden. this looks like it could be very easily blocked. how to deal with it?
[12:40:54] <ggm> I just realized we are doing Bill and Ben, the flowerpot men (for UK TV fans only)
[12:41:21] <ggm> Ben can have multiples. so diagram shows one foci but can have many focusses
[12:41:28] <ggm> Russ 2 Qs.
[12:41:45] <ggm> 1) why do you think it solves the problem? what happens when you roll over .UK root CA.
[12:41:47] <ggm> Ben oob
[12:42:00] <ggm> 2) looks like x.509 so why go GPGPGPG?
[12:42:42] <ggm> Ben because of the issuer consideration. certs are self-signed. we don't want the x509 chain rooting to the issuer.
[12:43:14] <ggm> Russ but not illegal. can have certs with same name
[12:43:19] <ggm> Mike RIchards 2Qs
[12:44:03] <ggm> 1) believe other side of slide is one with top & bottom is reversed. because DE cross signed UK. wasn't clear how., weather or knot there is a threshold, stub resolvers only trust whats going on if a minimum of cross sigs?
[12:44:13] <ggm> Ben not a goal, no. if decide I trust UK
[12:44:21] <ggm> then trust anything UK signs.
[12:44:35] <ggm> Mike then single trees but not everyone has same view. Graph, but pick trees.
[12:44:47] --- jc_lee has joined
[12:44:56] <ggm> 2) other Q. consensus? that we've given up key at "." and have bunch of rooted domains.?
[12:45:01] <ggm> Olafur no, not consensus.
[12:45:05] <ggm> Ben this is intermediate state proposal
[12:45:12] <ggm> and the chain down.
[12:45:13] --- jc_lee has left
[12:45:51] <ggm> Paul Vixie on simple key rollover
[12:46:31] <ggm> want simple mech. proposals too complicated. can't even read some of them.
[12:47:29] <ggm> wish to comment on the side, GPL is not enough. ISC use UC-Regents BSD style licence. GPL would poison the code. cannot use
[12:47:52] <ggm> concerned about the diversinet patent applies to almost anything. only recognized in .IL but can be internationalized easily
[12:48:18] <ggm> gives problem statement
[12:50:23] <ggm> cut/n/paste, http fetch. works on small scale. lab scale only.
[12:50:28] <ggm> timer based (stj)
[12:50:41] <ggm> threshold(johani) etc
[12:50:44] <ggm> DLV (vix)
[12:50:56] <ggm> actually DLV was soln to different problem
[12:51:49] <ggm> slide on why this is hard.
[12:52:59] <ggm> as rootop do NOT want people polling root for key rollover requests.
[12:54:07] --- weiler has left
[12:54:17] <ggm> proposes new zone apex RR. H(keyset). include in Auth section. then validators can trust.
[12:54:21] <ggm> oppertunistic optimization
[12:54:26] --- weiler has joined
[12:54:45] <ggm> can poll, beg people not to. use good half-lives to avoid over-polling
[12:55:05] <ggm> how different to NofM?
[12:55:33] <ggm> its always per-alg constant N, 2 is fine for RSA/DSA. avoids a policy knob
[12:55:43] <ggm> RR announces new keyset, validators won't have to poll
[12:56:04] <ggm> revokation is by omission. if its not published, its revoked
[12:56:27] <ggm> very lightweight. doesn't solve emergency rollover. solves problems we have, not all possible problems
[12:58:41] <ggm> some ideas on policy: always publish one key ahead, avoid key death. 50% lifetime overlap.. start using 2nd key at 25% life left
[12:59:33] <ggm> Roy Arendts. why new RR at apex? why not just keyrec?
[12:59:39] <ggm> Olaf. Size constraints.
[13:00:10] <ggm> big chunk of data. measured, dnssec with all clients ask dnssec info, dnskey biiiiig stack of data. eats b/w
[13:00:28] <ggm> Marg. general Qs? or general later?
[13:00:37] <ggm> Olaf if no further on this one..
[13:01:01] --- RussMundy has joined
[13:01:18] <ggm> Marg seems to me, IPR issues, complications, very different. trying to do, protect, seems different. don't have feel for consensus.
[13:03:53] <ggm> Olaf. need better handle on reqts.
[13:04:22] <ggm> Hum for work [hum]
[13:04:38] <ggm> Olafur so who will do the work?
[13:05:35] <ggm> the room is ducking for cover as the chairs assign work
[13:05:52] <ggm> Olaf. move to ML
[13:05:52] --- frodek has left: Disconnected
[13:06:44] <ggm> Thomas: sort-of interest, but work not getting done. not unique to this WG. asking wrong Qs. nobody will say no to 'work needed' but need to know priorities.
[13:07:07] --- maxwell has left: Replaced by new connection
[13:07:17] <ggm> Ed. Lewis
[13:07:41] <ggm> DNSSEC always been about resolver side up to now. interesting to move it to server.
[13:08:05] <ggm> zone ops, pushing out info about keys to use. consumer side, don't care about ops, care about ISPs. ISPs certify their trust.
[13:08:33] --- dblacka has left
[13:08:36] --- mrichardson has left: Disconnected
[13:08:55] <ggm> Olaf need requirements document. need metrics to move on
[13:09:31] <ggm> Interop Testing reports.
[13:11:04] <ggm> Nobomichi Ozoe TAHI DNS
[13:11:40] <ggm> 6th ETSI test. one client. one test tool.
[13:11:48] <ggm> found some bugs in both. no issue with DNS basic specs
[13:11:55] <ggm> go to www.tahi.org/dns
[13:12:13] <ggm> tahi released DNS test tool, v 0.1 download plz.
[13:12:30] <ggm> covers client functions, basic extensions on TCP/UDP on v4
[13:12:41] --- oatwillie has joined
[13:12:42] <ggm> will include server functions, mode additional functions, v6
[13:13:17] <ggm> details of test coverage in slidepack. 1034/1035, 1123, 2131, 2308, 3425 covered. 1995, 1996 not yet
[13:13:30] <ggm> 3596 covered, 2671, 2782, 3401-5 not yet
[13:13:54] <ggm> timeline. next tahi test event is 8th -January at Chiba JP (Makuhari)
[13:14:01] <ggm> April, v1 released
[13:14:46] <ggm> Olaf thanks.
[13:14:51] <ggm> now need to talk about WG futures
[13:15:06] <ggm> and the default action during last days of review
[13:16:09] <ggm> suggest 4-5 people minimum review to push forward. without that, block.
[13:16:17] <ggm> [hum in favour, mildly]
[13:16:39] --- suz has left
[13:16:40] --- suz has joined
[13:16:58] <ggm> Peter K. to the last item. not moving forward. what does it mean? die or leave on deliverables?
[13:17:12] <ggm> Olaf? no , not enough interest, drops from doc stack, have to do individ. submission
[13:17:39] <ggm> Sam. suggest, if no reviewers, doc Q changes to 'do we keep as work item' and if nobody supports drop
[13:17:46] <ggm> Don. minimum review count is good one.
[13:17:52] <ggm> Authors will have to get people to review
[13:18:35] <ggm> Future direction. process related advancement.
[13:18:47] <ggm> is the group viable? what should it be doing? charter review?
[13:20:50] <ggm> standing up for focussed work. two camps
[13:21:03] <ggm> Sam. as long as have critical mass, do as much as we can
[13:21:13] <ggm> two camps are key management, nsec3
[13:24:34] <ggm> Thomas: 3 months to get requirements, if you can't do it, then you have a signal
[13:25:11] --- weiler has left
[13:25:34] <ggm> Olaf. 5 minutes.. AOB?
[13:25:36] <ggm> Vix:
[13:25:46] <ggm> IPR.
[13:26:51] <ggm> aren't any GPLed OS implementations of DNSSEC. current or proposed. so WG have to realize that, unless there is a reason to believe the technology will be licenced at least as unrestricted as RSA/DSA, will be trying to deploy with none of current F/OSS impls helping. concerned as wg/impl/user
[13:27:03] <ggm> Thomas. vendor ships F/OSS versions of s/w. same problem.
[13:27:48] <ggm> Cisco person. definite issues. need licence which is not open-source/GPL
[13:27:56] <ggm> [missed one person who said need better than GPL]
[13:28:05] <joshlitt> mark stapp
[13:28:07] <ggm> Vix: BSD licence possible emerging as issue/requirement
[13:28:21] <ggm> Olaf. noted for reqts doc?
[13:28:23] --- mstjohns has left
[13:28:25] <ggm> concluded 2 mins early
[13:28:29] <ggm> <done>
[13:28:59] --- suz has left
[13:29:14] --- raj has left
[13:30:10] --- kivinen has left
[13:30:22] --- joshlitt has left
[13:30:34] --- fneves has left
[13:30:50] --- suresh has left
[13:30:53] --- suresh has joined
[13:31:13] --- oatwillie has left
[13:31:20] --- suresh has left
[13:33:29] --- rip-l has left
[13:33:40] --- RussMundy has left: Logged out
[13:42:00] --- robp has left
[13:42:06] --- FDupont has left: Disconnected
[13:44:47] --- ggm has left
[13:45:05] --- wrs1864 has left
[13:51:15] --- Olaf has left
[13:53:57] --- Peter Koch has left: Disconnected
[14:03:01] --- marka-isc has left: Disconnected
[14:10:39] --- dnsext has left
[14:37:33] --- mstjohns has joined
[15:25:05] --- mstjohns has left
[18:49:59] --- marka-isc has joined
[19:45:31] --- marka-isc has left