[01:39:50] --- rpayne422 has left
[01:39:53] --- rpayne422 has joined
[01:39:57] --- rpayne422 has left
[01:48:23] --- rpayne422 has joined
[02:32:33] --- peterd has left
[02:32:45] --- rpayne422 has left
[09:58:27] --- rik wade has joined
[10:16:22] --- dblacka has joined
[10:23:02] --- rpayne422 has joined
[10:27:48] --- matt_larson has joined
[10:39:26] --- jakob has joined
[10:41:40] --- mrose has joined
[10:41:57] --- ggm has joined
[10:42:14] <ggm> odd. I came here 2 mins ago.. nothing. oh well.
[10:42:23] --- mrose has left
[10:42:28] <ggm> Olaf asked for a scribe. I'll scribe if nobody else has a preference to be a scribe
[10:43:34] --- mlshore has joined
[10:44:38] --- galvinjamesm has joined
[10:45:16] --- olaf has joined
[10:45:51] --- mstjohns has joined
[10:47:10] --- yone has joined
[10:48:20] --- vlevigneron has joined
[10:48:21] --- brabson has joined
[10:50:23] --- vix has joined
[10:53:23] --- wes has joined
[10:54:12] <ggm> Olaf kicks off at 09:05
[10:54:41] <galvinjamesm> Thanks to the scribe!
[10:54:48] <ggm> administrivia. dave blacka is the real scribe
[10:54:58] <ggm> Olaf reminds people to speak names.
[10:55:06] --- brabson has left
[10:55:25] <ggm> Thus Aug 5, 09:00 - 10:15 (!) other dnsext work (second slot)
[10:55:31] --- Markk has joined
[10:55:48] --- peterd has joined
[10:55:49] <ggm> first slot (ie today) is DNSSEC work, 09:00 - 11:30
[10:56:09] --- jas has joined
[10:56:27] <ggm> DNS-MODA, Jim Ried, announcement (3min, no discussion)
[10:56:32] <ggm> DNSSEC deployment issues
[10:56:34] --- fneves has joined
[10:56:35] <ggm> Report on impl,
[10:56:42] <ggm> Key MGT issues, 2 drafts.
[10:56:52] <ggm> future work on denyal of existence, (60 mins)
[10:56:55] <ggm> Thus:
[10:57:02] --- leifj has joined
[10:57:07] <ggm> interop report
[10:57:16] <ggm> don eastlake on sha tsig alg.
[10:57:21] <ggm> austein nsid
[10:57:35] <ggm> wg administrivia (doc status & charter review)
[10:57:41] <ggm> Olafur on implementation report
[10:58:14] --- sakai has joined
[10:59:15] <ggm> olaf: who is trying to work on stuff other than servers.
[10:59:18] --- suz-isc has joined
[10:59:48] <ggm> Olaf: key management tools needed. bind-9 comes with dnssec-keygen. makes DNSKEY's and KEY recs
[11:00:03] <ggm> Olafur (sorry not Olaf above, its Olafur)
[11:00:29] <ggm> Tools to manage trust anchors: net-dns-sec-utils-trustedkeys (in Studlykaps)
[11:01:04] <ggm> RB-TrustAnchor. Mike St Johns to present on it late ron
[11:01:09] <ggm> Zone signing tools.
[11:01:20] <ggm> bind has dnssec-signzone. fully signs a zone.
[11:01:44] <ggm> NIST secure zone integrity checker -tool to check zone before and after ssigning for compliance with DNSSEC-bis
[11:01:53] <ggm> Rob Austien interjected bind9 will do incremental signing.
[11:02:01] <ggm> Servers
[11:02:13] <ggm> NSD. auth only server. full support
[11:02:23] <ggm> bind-9.3.0 in release, auth server.
[11:02:29] <ggm> End Resolvers
[11:02:33] <ggm> bind-9.3 has one
[11:02:41] <ggm> stub resolver with tsig/ad support
[11:02:51] <ggm> dig has new option to chase dnssec sig
[11:02:58] <ggm> DNSjava has stub resolver.
[11:03:00] <ggm> DRILL
[11:03:04] <ggm> Documentation
[11:03:30] <ggm> DNSSEC HowTO being written by Olaf (not Olafur:-)
[11:03:41] <ggm> NIST 800 series docs. coming to NIST website.
[11:03:44] <ggm> Testing tools
[11:04:00] <ggm> DNSSEC server benchmark test. scott rose, at NIST website
[11:04:25] <ggm> DNS(sec) API. none the same. even when exported. Q. does dnsext/dnsop wg think useful to standardize API?
[11:04:53] <ggm> discussion ongoing to extend API for v6 purpose. should we take on this on?
[11:05:32] <ggm> GetRRsetByName()
[11:05:44] <ggm> want to be able to pull out validation data about answer.
[11:05:47] <vix> getrrsetbyname(), without MixedCapsPlease.
[11:05:47] <ggm> Final comments.
[11:05:53] --- paf has joined
[11:05:56] <ggm> thats how he put it on the slide vix.
[11:06:51] <ggm> would be good if people decided to do interop testing. need 2 impl of every functional component to do interop report, to remove DNSSEC docs from PS (which they should be in, this year) to DS
[11:07:14] <ggm> Steve Crocker
[11:07:33] <ggm> With Russ Mundy, chairing DNSSEC deployment project, trying to track things, dovetails with this presentation.
[11:07:34] --- yushun has joined
[11:07:59] <ggm> From my perspective, have website under development, will coordinate with other websites, keep track of s/w etc. thinking as talk, good to have small team to maintain, bring up to date. who are
[11:08:04] <ggm> right person(s). Olafur!
[11:08:20] <ggm> two parts. agree needs place, will talk to you offline.
[11:08:22] <ggm> Bill Manning.
[11:08:36] <ggm> don't remember the IETF ever standardizing APIs in apps before. has come up over the years
[11:08:51] <ggm> Tomas Narten
[11:08:59] <ggm> we did in GSSAPI, not something usually done
[11:09:25] <ggm> Olaf K.
[11:09:35] <ggm> validation results need to travel up to app, so the app can make decisions.
[11:10:01] <ggm> validation may happen at another point in the network. need to travel to stub resolvers, so app can make decision. information you want to present is probably the same
[11:10:19] <ggm> Thomas Narten.
[11:10:32] <ggm> loose api. information that needs to flow has to be defined, not exactly an API
[11:10:45] <ggm> [would people prefer I tag each line by name? -ggm]
[11:10:48] <ggm> Rob Austein.
[11:11:08] <ggm> history of TCP. base spec lists conceptual functions, what they need to pass around. eventually people decided to use sockets API.
[11:11:09] --- mstjohns has left
[11:11:16] <ggm> Olafur
[11:11:46] <ggm> Related note, Bill Manning has arranged for a room to be available for small groups to get together, talk about DNS/SEC issues. brainstorming, interop tests if you want access talk to Bill
[11:12:32] <ggm> Next: Key Management (60 mins)
[11:12:39] <ggm> Punted before.
[11:12:48] <ggm> all know manual is not going to scale
[11:13:02] --- warlord has joined
[11:13:16] <ggm> going to have problems at the layer below root. both financial, costs money to deploy DNSSEC. need to recover, or cannot justify, also other issues.
[11:13:54] <ggm> number of schemas/approaches proposed. two presentations, then discussion, is this something we need to work on, take guidance, chairs take to WG ml, amend charter to take on work like this.
[11:14:03] <ggm> Mike St Johns, talking about his Schema.
[11:14:43] <ggm> draft-stjohns-dnssec-trustupdate-01.txt
[11:15:23] <ggm> Something in the path of the tree anchors trust. talk about how to deal with update to trust anchor. how you update keys in root, millions of resolvers.
[11:15:35] <ggm> definitions slide. trustpoint and trust anchor defined.
[11:15:49] <ggm> [ I don't know if his slides are available or not -ggm]
[11:15:55] --- stastny56 has joined
[11:16:49] <ggm> Design Goals for doc. survive N-1 keys (all but one keys) at a trust point. -minimize other attacks, eg adding new (compromised) keys by attacker. -ensure common state at resolvers, if they query DNSKEY RRset in defined time.
[11:17:17] --- rik wade has left
[11:17:30] <ggm> diagram of trust anchor state machine. the diagram is the 'heart and soul' of the document. go read the document I can't do ASCII art of this diagram !
[11:18:21] --- robdk has joined
[11:18:29] --- jakob has left: Disconnected
[11:19:05] --- Chris has joined
[11:19:05] <ggm> resolver does key checks. puts putative keys into check state. if key not invalidated during time period, moves into valid state. from valid state, if RRSet forces revoke, key is moved to revoke state.
[11:19:31] <ggm> if shows up as not present, 'state should not happen' key is still valid, but is not in RRSet. may be replaced, or revoked. operator error.
[11:19:37] <ggm> small changes to ID.
[11:19:41] <ggm> has state table.
[11:19:46] <ggm> this is what is going into DRAFT.
[11:20:52] --- leifj has left: Lost connection
[11:20:56] <ggm> one of the attacks which became interesting. if have two keys at trust anchor, one compromised, one attack is to add another key, without addhold bound, becomes immeidately valid, so attack becomes live quickly. if have hold time, then have window to test, can revoke key with remaining valid key. recommends to read document.
[11:21:06] --- norifmi has joined
[11:21:14] --- leifj has joined
[11:21:50] <ggm> examples. adding a trust anchor, assuming one existing trust anchor. 5 step process. 1) generate 2) create DNSKEY rec set SEP and zone key bits 3) add DNSKEY to RRSet 4) sign DNSKEY RRset ONLY with existing trust anchor 5) wait a while.
[11:22:03] <ggm> recommends standby keys, keep in the safe, useful administrative concept.
[11:22:27] <ggm> Example - deleting a trust anchor. assumes existing trust anchors A and B. want to revoke A.
[11:22:46] <ggm> 2 step process 1) set revocation bit on A. (people complained, changes on the wire proto)
[11:23:19] <ggm> 2) sign DNSKEY RRSet with both A and B. A is now revoked. operator SHOULD include revoked (A) in RRSet for remove hold-down time. then can remove from RRSet
[11:23:29] --- AndrewD has joined
[11:23:35] <ggm> 5.3 Key rollover
[11:24:15] <ggm> 4 stage process. 1) genersate new key pair C 2) add C to DNSKEY RRSet 3) set revokation bit on (eg) A 4) sign with A and B, A revoked, B is now active.
[11:25:05] <ggm> Example. Active Key compromise. the same as rollover mechanism. Same for Rollover.
[11:25:22] <ggm> Simple Scheme. timing is the problem. make sure it works with TTLs
[11:25:23] --- norifmi has left: Disconnected
[11:25:29] --- norifmi has joined
[11:25:52] <ggm> Ben Laurie. loose key? h/w device stolen you're screwed?
[11:26:04] <ggm> Mike? yes, but they can't use it.
[11:26:32] <ggm> can fix with Threshold key systems. can't fix nuclear war
[11:26:43] <ggm> Olafur. explicit q on draft, will take now. if generic, hold to later.
[11:27:05] <ggm> Vixie. Is this intended to be used by all secure zones? amount of churn, state in motion if 10,000,00 zones/resolvers try to communicate using this.
[11:28:05] <ggm> Mike. get this as default. 2nd gen added zone timer keys, to make sure, refresh. ideally, wont have a lot of trust anchors at resolver. try to manage 10,000 per resolver, problem at lightswitch level. works better higher up the tree, query top of tree on more regular basis than .com/int/us.
[11:28:34] <ggm> Bill Sommerfeld. implication of this is devices that are updating trust points, online continuously. not suitable for say rekey box put on shelf for some number of months.
[11:29:38] <ggm> Mike. depends. depends how fast swapping over the zones. typical lifetime. discusssion needed in dnsops. correct, if things offline for long enough, have to go fix/reconfigure. but have to do that anyway. something you do when plugged into network. eg do as DHCP option. no worse than caching resolver issues. various configs.
[11:30:05] <ggm> Russ Mundy. have you looked at the impact of doing a revocation intermediate zone, used as trust anchor. zone itself has to do work? impact?
[11:30:15] <ggm> Mike can't parse. Q. try again
[11:30:48] <ggm> Ross Tislabs used as trust anchor. com uses. person wants to revoke key at tislabs, take out of set, cause revoke thing to happen, but in the midst, ttl timeframe, alive in caches, still validate in resolvers
[11:30:55] <ggm> starting at root/com anchor correct?
[11:31:05] <ggm> Mike no. when you revoke, key is invalid
[11:31:10] <ggm> Russ but its in caches. you're stuck.
[11:31:21] <ggm> Mike. I cant force them to update. its pull world not push.
[11:31:40] <ggm> Russ so focus on resolvers which use trust anchor. if its in other resolvers, cached, its tough luck.
[11:31:54] <ggm> Mike if you're not using cache you will get revoke
[11:32:11] <ggm> Next Johan Ihren.
[11:32:19] <ggm> [is this ok? -ggm]
[11:32:38] <ggm> DNSKEY rollover.
[11:33:07] <ggm> caveat: draft is in rush state, aiming to get in for deadline. buggy text. crucial area, felt important to get this documented, for comparison.
[11:33:14] <ggm> [don't have URL to draft, or name -ggm
[11:33:16] <ggm> ]
[11:33:53] <ggm> Problem area same as Mike. validators will have to configure and maintain trust anchors. at least one, but probably more to many more need to be maintained.
[11:34:08] <ggm> at zone owner side, policies & procedures for key rollovers will be different from zone to zone
[11:34:35] <ggm> problems. 2 of them.
[11:34:52] <ggm> 1) how to bootstrap trust anchors. can existing trust relationships be used?
[11:35:12] <ggm> 2) how does a validator maintain its anchors once configured? how to track events?
[11:35:49] <rpayne422> draft name: draft-kolkman-dnsext-dnssec-in-band-rollover-00
[11:36:36] <ggm> implicit requirements no proto changes, keeping nminimum state, no specific timing issues, DNS only.
[11:36:55] <ggm> Johan not yet willing to constrain timing.
[11:37:12] <ggm> DNS only in the sense of completly based in the DNS
[11:37:58] <ggm> defines local policy to trust M of N keys, in rollover validation. if sufficient number of sigs match keys I trust, then will trust the new state.
[11:38:18] <ggm> key issue is to have multiple known validating sigs.
[11:38:57] <ggm> can be done outside of the resolver. its about resolver configuration. in theory, nothing to do with specific impl. separate management process. maintains key store, rotates old out and new in, in a schedule
[11:39:12] <ggm> skipping slides..
[11:39:18] --- robdk has left: Logged out
[11:39:25] <ggm> now on Implicit requirements
[11:39:28] --- jakob has joined
[11:39:59] <ggm> how to get device into this state. second, what if device is offline sufficiently long enough, to miss series of rollover events, now below M threshold in M of N trust decision.
[11:40:27] --- nevil has joined
[11:40:35] <ggm> dont have state diagram like mike, but situation is the same
[11:40:40] <ggm> Priming Concept
[11:41:20] <ggm> sign RRSet with private key, but public key is NOT in DNS. -the priming key. conceptually an 'uber' signing key.
[11:41:30] <ggm> distribute this using an existing trust relationship.
[11:41:41] <ggm> priming keys very long lived, larger keys.
[11:43:18] --- suz-isc has left
[11:43:39] --- suz-isc has joined
[11:45:01] <ggm> johan is discussing long lived key value in case of long-offline box, can re-bootstrap from uber key down.
[11:45:38] <ggm> What the draft is missing
[11:46:03] <ggm> not considering a class of replay attacks. can be fixed by maintaining state. eg log of trust anchors previously used
[11:46:30] <ggm> doesn't have thorough analysis of the client states. -what happens if the zone owner doesn't do what it MUST do et
[11:48:02] <ggm> Questions?
[11:48:05] <ggm> Bill Manning.
[11:48:28] <ggm> how do we test this?
[11:48:51] <ggm> Johan. Olaf has a mostly working implementation. entirely outside nameserver impl. not too difficult to do.
[11:49:23] <ggm> Bill Manning code is good, wonderful, but failure conditions have to do with 'how long' -in biosciences use things like fruitflies with short lives. how do we test these long-lived ideas.
[11:49:36] <ggm> Mike decided to simulate by advancing/compressing the time.
[11:49:47] <ggm> Bill simulations.... not real world...
[11:49:57] <ggm> Olafur its a general Q. will address later.
[11:50:33] <ggm> Mike St J. priming key. box on shelf for 2 years. box will have to look for RRSig generated by priming key. has to be updated when apex keyset changes. priming key has to come out of storage
[11:50:41] <ggm> Johan. priming key can't be in concrete bunker.
[11:51:21] --- jakob has left: Disconnected
[11:51:33] <ggm> Mike taking something more important than all other keys but use it like other keys. the 'one key' but can't leave it in the vault like in other (financial?) contexts. its the 'one ring' but its being used all the itme, so risk compromise
[11:51:48] <ggm> JOhan point well taken. but its not the 'one true ring' because we'll have several.
[11:51:58] <ggm> Mike: worse problem. any one of them can now be compromised
[11:52:17] <ggm> Johan no, the M of N concept protects you.
[11:52:25] <ggm> Mike not happy. [I think thats how he left it anyway -ggm]
[11:52:49] <ggm> Intermezzo: Vixie: on DLV. then more discussion of key-management. forgot the MODA announcement. and then NSEC++
[11:53:04] <ggm> Vixie.
[11:53:33] <ggm> DLV. I like the proposals from Mike/Johan, appear to extend architecture of DNS, cover case where parent not able/willing to publish verification key for you.
[11:54:12] <ggm> Vix part I dont like is they are coming at the 11th hour (sorry year) going to take time to test. wonderful idea should have been part of orig. design, comes up at last minute. happens all the time.
[11:54:51] <ggm> Vix recognizing this, hooked up a scheme called DLV DNSSEC L-ookaside V-alidation. 4 page spec. NOT an internet draft, in part because its so ugly, can't find people to credit as authors.
[11:55:42] <ggm> Vix idea here is to put DNS recs into a zone, look in that zone for DS records if you receive an insecure answer, and you don't know absolutely it SHOULD be insecure. neeeds changes to cacheing model, have synthesized the neg results, to avoid pummeling this alternate security server with every query
[11:56:16] <ggm> Vix in bind 9-3., not in release candidate but have high hopes. registry for it, anyone can run, ISC is going to run one. presumable other ones, in intranet context, eg .MIL
[11:56:38] <ggm> Vix not sure this will be a draft, but does need to be published in case non-bind people want to exploit
[11:57:48] <ggm> Vix not designed to scale. if DS becomes suffiently popular it doesn't scale well. once there are a million people with .COM DS recs to put into .COM zone, then Verisign can say $$$$ in it, and the need disappears. not supposed to be change to arch, long term entitiy. one failure mode is DLV works well enough to spoil 'right solutions' but not personally worried. thats DLV
[11:57:58] <ggm> Olafur. DLV Questions to Paul.
[11:58:15] <ggm> Mark Kosters, the way DLV being proposed, configured per zone? or ...
[11:59:17] <ggm> Vix possible to declare DLV hierarchy corresponding to any domain in tree. Eg if Verisign wants to run DLV tree for .COM, and can get people to look at you for DS keys, you can do it. .MIL would consider this, but I don;t think this is realistic for every person in the internet.
[11:59:18] --- yushun has left
[11:59:28] <ggm> Mark K. guessing, is there going to be a default if there is no per-zone thing?
[12:00:06] <ggm> Vix no. do have default for root hints compiled in, not any intent to do this with DLV. too controversial,. the ISC registry will start at root, anybody wanting to do DNSSEC in advance of being in root will
[12:00:38] <ggm> ahve to talk to us. the way we intend to publicize this, our registry for the root of the real tree, is in readmes for things. but it WILL NOT be the default. have to take explicit action
[12:00:44] <ggm> Olafur has one Q.
[12:00:49] <ggm> using DS recs or some other record
[12:01:30] <ggm> Vix have different record type, DLV rec, has exactly the same info as DS rec. has to live for a lot longer than we think, has to get bigger than single zone, this alternate hierarchy will have to sub-delegate, will need normal DS to secure those things.
[12:02:11] <ggm> Olafur. thanks to all presenters. impressed with diversity. now want to go open-mike for 10 mins on key management, opinions on key management, should WG go into this area. silence will be taken as no.
[12:03:08] <ggm> Russ. very important area. WG needs to look at this, and entertain more ideas . fixing validaters is hard problem. need to do this.
[12:03:17] --- Chris has left: Replaced by new connection
[12:03:27] <ggm> Rob A. need to do this. not as depressed as some people that its not been done yet. separate problem. reasonable to do this work.
[12:03:45] <ggm> Johan without anything like this, risks high
[12:04:03] <ggm> Mark Andrews. definitely think we should research solutions.
[12:04:59] <ggm> Olafur. next step: will coordinate with AD, DNSOP wg people. straddles groups. needs charter changes. will take to ML allow diverse proposals, advance multiples or work to single. DONE.
[12:05:10] <ggm> Jim Reid on MODA announcement
[12:06:10] <ggm> dns://moda
[12:06:20] --- jakob has joined
[12:06:22] <ggm> DNS Manufacturers, Operaters & Developers Assoc.
[12:06:29] <ggm> membership based.
[12:06:42] <ggm> this is NOT an ISC venture, dispite mail being sent from @isc address.
[12:06:51] <ggm> progress DNS proto, develop APIs etc.
[12:07:15] <ggm> intro meeting this evening, 18:30 in skyline room, of the Hilton (10 minute walk) 9th floor
[12:07:36] --- Chris has joined
[12:07:43] <ggm> Olafur NSEC++ control now passed to Olaf K.
[12:08:15] <ggm> Olaf. NSEC walking *is* a (perceived) barrier to deployment.
[12:08:41] --- lars has joined
[12:08:45] <ggm> Olaf: the WG cannot force DNSSEC-bis to be deployed and may speed deployment *if* a solution is found.
[12:08:53] <ggm> Olaf: therefore have to consider this seriously.
[12:09:06] --- lars has left
[12:09:09] --- mstjohns has joined
[12:09:10] <ggm> Olaf: have to know what the requirements are before we can start to engineer.
[12:09:50] <ggm> two proposals on the table. one by Ben Laurie, one by Roy Arends (?) . can they be incorperated now? open Qs? issues?
[12:10:26] <ggm> there may be other solutions. eg 'white lies' schemes, cook NSEC up on the fly. may work. different complexity/security problems.
[12:11:01] <ggm> need to discuss. requirements AND proposals. interactions with proto. do not measure during meeting, decision is on the list.
[12:11:13] --- jakob has left: Disconnected
[12:11:17] <ggm> animated slide of humour
[12:11:23] --- stastny56 has left: Disconnected
[12:11:32] --- leifj has left: Disconnected
[12:11:40] --- leifj has joined
[12:11:50] --- mlshore has left: Disconnected
[12:11:53] <ggm> Ben first, then Roy,
[12:13:06] <ggm> Ben Requirements for a proof of non-existence.
[12:13:34] <ggm> not a full set, just things we thought of, not ML outcomes
[12:13:47] <ggm> zone contents: zone enumeration, zone size
[12:14:13] <ggm> can guess size based on 'distance' between first and NXT recs. can guess . some people think you shouldn't be able to
[12:14:48] --- mlshore has joined
[12:15:20] <ggm> suggested only single RR for both old- and new- style denyals. don't understand that requirement but there it is. empty non0terminals.. should stay empty but EXISTS fills them. if you don't fill them then this leads to very long labels.
[12:15:25] <ggm> some people thinks this is bad.
[12:16:17] <ggm> prevention of dictionary attacks -dont want people to be able to make dics, run hash alg. look stuff up. so need to use salt,
[12:16:56] <ggm> zone growth. want support of opt-in. to ease transition. some people think its bad if the hash is the same as a real domain name. eg trademark and other IPR issues.
[12:17:05] <ggm> [hmmm. when I say Roy do I mean Rip? -ggm]
[12:17:12] <ggm> Questions?
[12:17:36] <mstjohns> No - Roy will be talking next
[12:17:47] <ggm> [phew! thanks -ggm]
[12:18:46] --- yushun has joined
[12:18:48] <ggm> Roy: explain some more in a few secs . with empty non-terminals, stay empty or fill with long labels. if you make them non-empty, have exist recs, end up with more recs.
[12:19:24] <ggm> Russ. probably for chairs as much as Ben. plan is, to get published as ID, take to list, discuss requirements, flesh out, understand better. couple Ben doesnt understand, more than couple I don't understand so want to flesh out.
[12:19:31] <ggm> Ben are more specific info in the draft
[12:19:52] <ggm> Nic ? is Draft going to include discussion of why?
[12:20:04] <ggm> Ben yes, but we dont have to, its given job we are doing this.
[12:20:22] <ggm> Ben Some TLD will not deploy DNSSEC without this being solved.
[12:20:55] <mstjohns> url - http://www.links.org/dnssec/requirements.txt
[12:21:03] <ggm> Olaf. Q I have, hope to have in requirements, is this needed to prevent full enumeration 100%? eg is a fraction ok? sufficient to just raise the bar? specifics in draft?
[12:21:32] <ggm> Ben no, but its one of my own requirements forgot to add, DNSSEC should not make it any easier to walk zone than DNS already does. approximation measure there. as it stands DNSSEC makes it
[12:21:34] <ggm> much easier.
[12:21:51] <ggm> Where did requirement not to know size of zone from?
[12:21:54] <ggm> Ben in the draft
[12:22:15] --- amarine has joined
[12:22:18] <warlord> (from Simon, he said)
[12:22:40] --- paf has left: Disconnected
[12:23:07] <ggm> Olaf. one of the things we had, pre-requisite. to make DNSSEC-bis go out the door, at least a transition mechanism to new method of preventing, new RR, should be transition from DNSSEC-bis that is backwards compat. did on list during last call. Peter has made inventory of that, together with Roy, Jaak (?)
[12:23:23] <ggm> Peter Koch
[12:23:43] <ggm> Authenticated Denial mechanisms
[12:23:55] <ggm> draft-ietf-dnsext-dnssec-trans-00.txt
[12:24:39] <ggm> discussion came up in may/june, work done in 10 days. posted draft mid-june
[12:25:18] <ggm> have done survey of mechanisms. grouped into two. first 9. require updates to DNSSEC-bis probably a problem, but should abstain from judging.
[12:25:49] <ggm> dynamic NSEC synth *may* get away without changes to DNSSEC-bis, but more involved changes would require changes in -bis.
[12:26:31] --- paf has joined
[12:26:55] <ggm> versioning/subtyping of NSEC rec. (would change RDATA format) - using or abusing the type bitmap NSEC indicator to signal - New Apex type. (new RR needed attacheed to apex) - NSEC white lies (comes in different flavours) - and NSEC optional via DNSSKEY flag
[12:27:18] <ggm> [mmmmmmmmm NSEC white lies... in flavours... MMMMMMmmmmmmmm (homer)]
[12:27:48] <ggm> other group of 3. comprising methods/ proposals which dont need updates to DNSSEC-bis. but dont give immediate soln.
[12:28:04] --- jakob has joined
[12:28:15] <ggm> partial typecode rollover. ship as-is, work on proposals, auth deny, when agreed solution, type code rollover again
[12:28:23] <ggm> [I am guessing jaak above is Jacob. sorry -ggm]
[12:28:32] <ggm> A complete type code and sig rollover.
[12:29:05] <ggm> or use unknown alg in RRSIG, register with IANA a new ALG for RRSIG, including information about auth denyal
[12:29:36] <ggm> Recommendation. start work on partial Typecode Rollover and meanwhile use NSEC synthesis.
[12:30:02] <ggm> proposed next steps.
[12:30:57] <ggm> want to get document out, inc comments received so far. send 01 to WG last call if discussion terminates. target is informational RFC. collection of ideas, not summary of details/proposals, not implementation guide., just ideas. solicit comments!
[12:31:00] <ggm> Q
[12:31:57] <ggm> Steve Bellovin few of us were talking about this, idea, short length, short lived keys used for online signing. lifetime of a day, dont care if compromised, cheap to do calcs for signing. may be different path
[12:32:13] <ggm> Olaf: in combination with white lies?
[12:32:13] <ggm> Steve, well, for dynamically generated NO stuff.
[12:32:14] --- norifmi has left: Disconnected
[12:32:24] --- norifmi has joined
[12:32:40] <ggm> Peter. one method where need, if believe online key can be compromised more easily than offline, then without indication key is dedicated to NEGS key can be used for +ve answers
[12:32:52] <ggm> Steve may want to use eg for DDNS, came up with idea last night, not fully baked.
[12:33:08] <warlord> This idea was discussed online a couple months ago.
[12:33:47] <ggm> Johan has been thought of before. one benefit of DNSSEC. distance of zone/data owner to resolver/consumer, certain amount of auth resides with authority bit holder. with DNSSEC we remove that.
[12:34:28] <ggm> move to zone owner. if we move to online signing keys we change security perimiter in direction we dont want to go. auth servers run by multiple people, not associated with zone owner, not good direction to go.
[12:34:45] --- jakob has left: Disconnected
[12:35:06] <ggm> Peter in theory yes, current practice, have secondary service, operated by people not associated
[12:35:25] <ggm> Johan having multiple orgs running TLDs is standard practice, single registry owning all NS is not standard. may change but is not way it is today
[12:35:40] <ggm> Peter have to weigh cost:benefit issues. want to prevent zone enumeration or not?
[12:36:21] <ggm> Markus DENIC. soundling like logical clash. wg document recommending me to use NSEC white lies, using this method of updating DNSSEC-bis, but we are not updating. if I do white lies, I'm not compliant with RFCs
[12:36:36] --- sakai has left
[12:36:42] --- mstjohns has left
[12:36:54] <ggm> Peter white lies stuff comes in different flavours. probably not RFC compliants to NSEC requirements, but are you afraid of the protocol police? there are none!
[12:38:17] <ggm> Olafur. process issue. one of the items we asked be investigated by design team is, what can be done in proto today to address this. they identified white lies as candidate to be protocol compliant. also want to consider changes to types or other things, then other method looks more promising. thats what they did. its up to WG. take recommendations at face value. not recommending you lie, we havent specified proto method. havnet got to that point yet.
[12:38:36] <ggm> Rob Austein. have interesting requirement fleshing-out to do here.
[12:38:56] <ggm> need to think about special cases
[12:40:31] --- mstjohns has joined
[12:40:56] --- admcd has joined
[12:41:31] --- admcd has left
[12:41:54] <ggm> NSEC3. roy arends
[12:42:16] <ggm> same function as NSEC, with measures to increase zone enumeration cost.
[12:42:53] <ggm> lists nexts next NSEC3s canonical ordered, optionally hashed owner name. owner name can be hashed, has opt-in.
[12:43:22] <ggm> NSEC3 hash labels are individually hashed. preserves empty non-terminals. to avoid EXIST
[12:43:38] <ggm> Labels are optionally hashed. if want back-compat with NSEC, don't hash.
[12:43:52] <ggm> salt is 24 bits in proposal, to prevent dictionary attacks, but can extend.
[12:46:37] <ggm> discussion in draft on hash tuncation to smallest unique value. -truncation causes higher collision probability. limited to the probability to spoof non-existent names as existent. but its not possible (with NSEC3) to push existing names into non-existent.
[12:47:44] <ggm> why opt-in? orig. draft/methodology sound, implemented. its orthogonal, and its optional.
[12:48:50] <ggm> current draft at http://www.logmess.com/~roy/
[12:48:59] <ggm> Olaf. defer discussion until later.
[12:49:18] --- rgaglian has joined
[12:49:25] <ggm> Ben Laurie NSEC2
[12:49:46] <ggm> short presentation
[12:50:27] <ggm> make enumeration hard by hash, salt, and iterations to increase cost.
[12:50:56] <ggm> NSEC2 rec, with hased ownername, hash alg, iterations (24 bits) Salt (32) RR type bitmap Next hashed label.
[12:51:23] <ggm> Exists empty non-terminals to prove existence of empty non-terminals, but makes them non-empty. NSEC2 hides them.
[12:51:34] <ggm> Opt-in Is not allowed for, but it could be trivially.
[12:51:56] <ggm> http://www.links.org/dnssec/draft-laurie-dnsext-not-existing-01.txt
[12:52:22] <ggm> Sam Weiler, summary
[12:52:48] <ggm> summary of old NSEC problem statement
[12:54:18] --- yushun has left: Disconnected
[12:54:42] <ggm> shows how hashing and changes to canonical ordering improves things. no change in size, some effects on labels, but reccount stays the same
[12:54:51] <ggm> Roy depends. if you have EXISTS recs, then do increase
[12:55:41] <ggm> Sam both algs allow choice of alg, salt. canonical order only apply to NSECs. change hash/salt, change range of names covered. could be interesting. no NSEC recs about NSEC recs.
[12:55:50] <ggm> big difference between approaches is what is hashed.
[12:56:33] <ggm> NSEC2 hashes entire thing. NSEC3 hashes sub-domain of names. NSEC2 EXISTS RR proves existence of empty non-terminals. exposes, names of empty non-terminals.
[12:57:24] <ggm> NSEC3 exposes structure, but not names of empty non terminals. attack doesnt work for ENUM or other deep zones.. but can attack ENUM with dictionary trivially
[12:57:50] <ggm> Ben no, doesn't because unless delegate every number, cant enumerate. Sam maybe not in Bens, can in Roys.
[12:58:11] <ggm> NSEC2 has hash iterations to increase costs of hashing. but that costs is also for rootservers as well as dictionary attackers
[12:58:25] --- norifmi has left
[12:58:27] <ggm> NSEC3, has opt-in back in. defines null hash function (plaintext names)
[12:58:37] <ggm> all three are things which could be picked or chosed or mixed.
[12:58:42] <ggm> Problems
[12:59:22] --- sommerfeld has joined
[13:00:00] <ggm> hash collisions problem. can be used to spoof each recs data 'away'
[13:00:11] <ggm> Ben if SHA1 has collision, then dead anyway, because its used in signatures.
[13:01:00] <ggm> Sam if starting its easy, just choose hash func to avoid. but if adding to existing, cannot change. or, havent been documented. -need to roll through insecure state to re-hash
[13:01:10] <ggm> Steve Crocker. do you really think there are going to be collisions.
[13:01:15] <ggm> Sam need to consider risk.
[13:01:24] <ggm> Steve using SHA1 or something deeper.
[13:01:38] <ggm> Sam its not the hash function, its the bitcount. if only using 48 bits, then collision risk is higher.
[13:02:00] --- leifj has left
[13:02:31] <ggm> Roy: in my world, hash collisions are avoidable since generated before serve. either change hash func, or salt. when doing incrementally, have to find/know hash collision, check. resign whole zone.
[13:02:38] --- galvinjamesm has left
[13:02:47] <ggm> Sam but thats what I said
[13:02:52] <ggm> Roy I dont see this as a problem.
[13:03:03] <ggm> Olaf. Want to handwave collision problem away to list.
[13:03:30] <ggm> Ben. I think you are wrong about hash/salt. included in each NSEC2 rec,
[13:03:34] <ggm> Sam also take offline.
[13:04:37] <ggm> Paul Vixie Sam, thanks for presentation. now understand NSEC2/3 better, from your explanation. comment on deployment timeline. interesting, but .. how long to deploy could be longer than DNSSEC. rose coloured view. if chosen, which calender year to do we deploy?
[13:04:42] <ggm> Sam covered in2-3 slides time.
[13:05:37] <ggm> Recursion problem. proponents will say 'the situation doesn't happen' but I'm not convinced.
[13:05:58] <ggm> Summary: big differences, name covered by the hash, implications for wildcard processing, hashing per-labels.
[13:06:30] --- paf has left: Disconnected
[13:06:46] <ggm> Both docs ambiguous/inconsistent. Wildcard processing not well understood. broken example in NSEC2, no examples in NSEC3. what to do with collisions, no good way to roll salt/hash, possible recursion problem.
[13:07:42] <ggm> Timeline to show DS draft as 3 year lifetime. DNSSEC-bis estimated 1 year, went to IESG 3 years later.
[13:08:06] <ggm> Olaf. open mike
[13:08:39] --- jakob has joined
[13:09:31] <ggm> Peter Koch. identify two problems. hash collisions risks. I don't think this is strong. second, protocol hygene, not pointing hashes back into same namespace (recursion) open up parallel namespace or whatever. so wildcard is third problem, given that strongest proponents to zone enumerations are TLD, most of us know what we think about wildcards in TLD, just ban it. what remains?
[13:09:58] <ggm> Sam. bad ideas from the past keep coming up. wildcards and opt-in were discussed for ban some time ago.
[13:10:38] --- jakob has left: Disconnected
[13:11:06] <ggm> Rob Austein. Sam pointed out, agree, is understanding implication of hashes on names. cant have informed opinion until I see a worked example. need to see this, verify examples match description.
[13:11:36] <ggm> Mark Andrews. collision problem. one solution space, second independent hash on data. avoid
[13:11:42] <ggm> Sam expanding number of bits
[13:11:53] <ggm> Mark dramatic effect on probability of hash collision.
[13:12:30] <ggm> Olafur thanks for v good presentation. not chair, WG member, is why do we need this? get requirements done, before we try and work out how to solve it. still have to be convinced problem requires this.
[13:12:45] <ggm> worried about times./timelines. even if we get better, still it takes years.
[13:12:53] <ggm> Olaf K. do we share this opinion? [yes]
[13:13:06] <ggm> Olaf. bring requirements discussion back to list
[13:14:29] <ggm> Mike zone enumeration, how much of a problem today?
[13:15:09] <ggm> Mark Klosters. this is where business world rules make impositions on technology., its a constraint we have. outside the bounds of this group. we have this constraint, are we willing to listen to it, may make
[13:15:16] <ggm> DNSSEC deployment more available.
[13:15:22] <ggm> Olaf thats the approach I am taking
[13:15:37] <ggm> Mike. do we have a list of NS, can we detect dictionary attacks?
[13:15:49] --- vix has left: Logged out
[13:16:00] <ggm> Mark K. this is a concern outside this body. allows people to go outside their AUP to see information.
[13:16:25] <ggm> Jeff nominet UK we have seen frequent dictionary attacks, believe many more not detected eg use of distributed clients, unprotected resolvers.
[13:17:05] <ggm> Olaf. reuqirement not yet in document, level of ease should be at least same, or less, this is an important requirement to measure effectiveness of solns. urge people who have the reuqirement in business to give input to document/WG so we can see if solns are real.
[13:17:16] --- mstjohns has left
[13:17:32] <ggm> Kent Crispin ICANN. worried about very large zones. also are very small zones. not susceptable to dictionary attacks, but people may still not want them exposed.
[13:18:20] <ggm> Russ Mundy. emphasise Olafs point. need to get DOCUMENTED state of problem. requirements. from business/operation/whatever. for WG to discuss. then discuss solutions.
[13:18:28] --- amarine has left
[13:18:40] <ggm> Olaf. Meeting closed. 09:00 Thus. thankyou
[13:18:44] --- wes has left
[13:18:50] --- warlord has left
[13:18:54] --- rpayne422 has left: Logged out
[13:19:11] --- peterd has left
[13:19:12] --- Markk has left
[13:19:23] --- jas has left
[13:19:39] --- yone has left
[13:21:38] --- dblacka has left: Disconnected
[13:27:44] --- fneves has left: Disconnected
[13:28:05] --- olaf has left
[13:30:20] --- suz-isc has left
[13:33:05] --- nevil has left
[13:33:24] --- matt_larson has left: Disconnected
[13:36:56] --- mlshore has left: Disconnected
[13:37:09] --- AndrewD has left: Disconnected
[13:38:39] --- ggm has left: Disconnected
[13:39:14] --- Chris has left
[13:39:27] --- vlevigneron has left: Disconnected
[13:40:47] --- rgaglian has left: Disconnected
[14:35:23] --- jakob has joined
[14:35:34] --- jakob has left
[14:36:48] --- brabson has joined
[14:37:31] --- dinakar has joined
[14:37:36] --- brabson has left
[14:37:39] --- dinakar has left
[14:43:47] --- paf has joined
[14:58:47] --- rgaglian has joined
[14:58:51] --- rgaglian has left
[14:59:15] --- stastny56 has joined
[14:59:24] --- paf has left
[14:59:36] --- stastny56 has left
[14:59:55] --- AndrewD has joined
[15:00:09] --- AndrewD has left
[15:02:25] --- dblacka has joined
[15:02:36] --- dblacka has left
[15:12:28] --- peterd has joined
[15:12:52] --- suz-isc has joined
[15:13:01] --- suz-isc has left
[15:13:34] --- suz-isc has joined
[15:14:44] --- suz-isc has left
[15:15:10] --- suz-isc has joined
[15:15:21] --- suz-isc has left
[15:39:18] --- suz-isc has joined
[15:39:26] --- suz-isc has left
[15:39:52] --- suz-isc has joined
[15:41:23] --- suz-isc has left
[15:56:45] --- orange has joined
[15:58:16] --- orange has left
[16:00:22] --- sommerfeld has left
[16:22:03] --- peterd has left
[18:51:32] --- pawal has joined
[18:52:21] --- pawal has left
[20:16:13] --- darrin has joined
[20:16:38] --- darrin has left
[21:44:40] --- vlevigneron has joined
[23:45:41] --- vlevigneron has left: Disconnected