----------------------------------------------------------------------------- WG: DNS Operations (dnsop) Meeting: IETF 77, Anaheim Location: Anaheim Hilton, "California A" Date: Wednesday, 24 March 2010 Time: 13:00 - 15:00 (UTC-7) Chairs: Peter Koch Stephen Morris Jabber: xmpp:dnsop@jabber.ietf.org WG URL: http://tools.ietf.org/wg/dnsop/ Agenda: http://www.ietf.org/proceedings/10mar/agenda/dnsop.txt Material: https://datatracker.ietf.org/meeting/77/materials.html ----------------------------------------------------------------------------- 1) Administrivia [chairs][5 min][13:00] - minutes scribe Rob Austein - jabber scribe Wes Hardaker Stephen was introduced as the new co-chair. 2) Status Update [chairs][5 min][13:05] Status has been sent to the mailing list (http://www.ietf.org/mail-archive/web/dnsop/current/msg08292.html). Two documents (draft-ietf-dnsop-as112-ops.txt and draft-ietf-dnsop-as112-under-attack-help-help.txt) have references to the local zones draft (draft-ietf-dnsop-default-local-zones.txt); the latter may require updating. 3) Active Drafts 3.1) DNSSEC Signing Policy & Practice Statement Framework draft-ietf-dnsop-dnssec-dps-framework-01.txt [Fredrik Ljunggren][10 min][13:10] Very few comments so far, only minor updates. .SE have revised their DPS, which has been published (https://www.iis.se/dl/DPS-PA9-ENG.pdf) under a creative commons license. Peter Koch: 3-5 people other than authors have read current version, need more readers. 3.2) DNSSEC Trust Anchor History Service draft-ietf-dnsop-dnssec-trust-history-01.txt [Olaf Kolkman][10 min][13:20] Wouter Wijngaard's document was presented by Olaf Kolkman. The goal is an easy way to update a key set when the it has expired by following a plausible chain of records and signatures from your old state to the current state. It proposes a new TALINK RR (type 58). The current draft documents security policy choices. It encourages use of RFC 5011, provides alternatives for cases where that is not practical, and should warn operators if changing keys. The authors think the document needs another revision, mostly for stylistic issues, after which it is hoped that it will be ready for WGLC. About ten people have read the document. Jakob Scklyter: Wants to know if there are implementations. - Olaf Kolkman: We are aware of one implementation. Andrew Sullivan: Thinks it is not yet close to WGLC; as well as stylistic issues he also wants clarifying text on a few issues. - Olaf Kolkman: There may still be a roll-over-and-die issue in the document; we need to be careful about query load given all the things one might need to check. Peter Koch: Concerned that there may not be many use cases if the world really does go to single root trust anchor. - Olaf Kolkman: Part of the point here is supporting machines that stay shut off for periods of time on a regular basis; also, enterprises might have local trust anchors for internal use. - Olafur Gudmunsson: Worry about installing from old DVD, not just machine on shelf. - [missed name]: This has applications even if most of world uses single trust anchor. 3.3) DNSSEC Operational Practices, Version 2 draft-ietf-dnsop-rfc4641bis-02.txt [Olaf Kolkman][30 min][13:30] Since the last version, have resolved issues on HSMs, NSEC-NSEC3 considerations. Open issue (typecodes) for RSASHA256. Scott Rose (NIST) has reviewed the NIST material in the draft. Many issues addressed (all believed resolved) on ZSK rollover frequency, flawed cryptography, timescales, and assumptions surrounding rollover; section 3 has been rewritten to stress operational considerations as driver for (rather than result of) crypto parameters; it needs review. Andrew Sullivan: The language not yet cleaned up enough, it still assumes frequent rollovers in places. Substance OK, just cleanup. - Olaf Kolkman: Yep, see "needs review". Jelte Jansen (via Jabber Scribe): Don't consider key algorithm rollover resolved in current text. - Olaf Kolkman: Please send more details to the list. Olaf Kolkman: Added section 4.4.5.2 about non-cooperating DNS operators. This is mis-named, as it is really about how you prevent vendor lock-in when an operator holds a victim's private keys. The issue is considered closed other than needing review of the figure. - [Missed name]: Non-cooperative case not solvable, what I'm looking for is guidance on how to move zone in cooperative case. - Olaf Kolkman: Thinks this is covered, please take to list. Peter Koch: Five people have reviewed this operator text but none are operators. The document needs more reviewers. Olaf Kolkman: The status of the document (currently set at BCP) is to be addressed later. This is a living document; at this point, we're working on version 2, we expect at least a version 3. We're trying to close off issues so it is currently not ready for WGLC. Roy Arends: Lots of people (~50) attended DNSEXT and saw discussion of "roll over and die". That relates to this document in KSK rollover frequency. Roy will send his concerns to DNSOP mailing list. Olaf Kolkman: Wants review of section 3, particularly 3.1.2.1, the distinction between KSK that is or is not a trust anchor, plea for conservatism when rolling trust anchors. The document still advises exercising the process on regular basis. - Geoff Huston: Argue that we should roll over early and often is like advising that we should crash cars early and often to build better cars. Geoff does not buy the argument that crashing early and often produces a better product. - Olaf Kolkman: Need more research, but what we found in "roll over and die" was a broken implementation. A better analogy would be testing a standby generator. - Roy Arends: It would be more productive if the document had more granularity (detail?) on reasons for doing rollover. It also should separate the view from the authoritative server from the view from the validator. Will send text. - Sam Weiler: Geoff's analogy is wrong, Olaf's is right. You test brakes to find out if they fall off the car. - Ed Lewis: Rolling a key is a normal operation. You want to roll keys to protect from other operational things, e.g. people leaving the data center, etc. - Olaf Kolkman: The big elephant in room is the root. If we don't roll it until something bad happens, that will probably be too late to find out whether rolling works. Shipping static data in distribution was a mistake; now we know, industry is aware. - Andrew Sullivan: The document is not entitled "key management for the root zone", it is a general purpose document. It would be serious mistake to put bunch of rules in to solve one zone's (root's) problem that had to apply to every zone. Don't think recommending regular rollover for non-root zones is a good idea; it might be a bad idea. The current draft is slanted towards large infrastructure zones. - Olaf Kolkman: Fair enough, the question is where to draw the line. We want considerations clear enough that document readers will understand that choices are different. - Rob Austein: Glad we tested early so we found ROAD problem while the population was still small. This is not the last bug we will ever find in DNSSEC, let's please find them early. - Jim Galvin: Need to distinguish two circumstances: what we do in beginning vs what we do steady state. [Missed a couple of sentences] And yes, auto manufacturers do crash cars to test them. Some people will want to exercise process, some will prefer stability. Matt Pounsett: Don't want specific recommendations for root. Options that don't get exercised don't get maintained; does not necessarily need to be in production, can be in lab, but hard to simulate all of it in lab, particularly parts that are inter-organization. They do need to be necessarily frequent, but regular rollovers are necessary so people will remember what to do. George Michaelson: Doesn't think document is quite right choosing key lengths. The justification is missing and real cryptographers hedge when asked these questions. This goes to rollover, why do we have to withdraw old key? - Olaf Kolkman: Agree on answers we get from cryptographers; tried to follow approach of "what are our needs?" and derive key length from that. - George Michaelson: Have we ever lived through serious trust anchor compromise in any commercial PKI? We have not practiced this stuff anywhere. - Olaf Kolkman: There is no way to change PKI certificate stores in practice, this is a different game. Joao Damas: If we hadn't done rollovers, the "roll over and die" problem would not have occurred. Want recommendation: if your parent is not signed, don't just go with static trust anchor, use RFC 5011 or DLV. - Joe Abley: Scheduled and emergency key rollovers are very different things. In an emergency you don't have time to use normal procedures. There are enough differences that scheduled is not really practice for emergency, so don't justify scheduled as practice for emergency. Olaf Kolkman: RFC 4641 strongly recommended separating ZSK and KSK issues, wants help from chairs here: is assumption that you need to introduce new key material a prerequisite for DNSSEC, and do you need practice rollover as a consequence? Previous assumption was "yes", if answer has changed, please tell the document author or, better, volunteer to write a different document. - Peter Koch: This is postponed to list. Clearly we can't keep changing assumptions out from under document in progress. 4) Other (non WG) Internet-Drafts 4.1) DNSSEC Key Timing Considerations draft-morris-dnsop-dnssec-key-timing-02.txt [Johan Ihren][10 min][13:55] Very close to becoming WG doc, but it is still independent. Both KSK and ZSK rollover fully treated, and the draft is now more neutral on alternatives. We were asked to cover all rollover mechanisms, so did. Unclear on whether should cover algorithm rollover, document does mention it but not as fully as key rollover. This topic may warrant a separate document; we don't have enough experience with algorithm rollover yet to write much about it. Does WG want to adopt this? 10 have read latest, 15-20 have read some version. Authors of this and 4641bis agree that this doc should be separate from 4641bis. ~25 in favor of adoption, no objections, need to confirm on list but assume it is now a WG document. Unless the list says otherwise, it remains separate from 4641bis. 4.2) Reverse DNS in IPv6 for Internet Service Providers draft-howard-isp-ip6rdns-03.txt [Lee Howard][10 min][14:05] ISPs pre-populate reverse zone in IPv4 but can't in IPv6. This is an informational draft to document what options ISPs have and the considerations for each. 10-15 have read document. David Hankins: does the text really say say need FQDN option to do DDNS? 'Cause that ain't so. Maybe it's dependent on reconciliation of domain names? - Lee Howard: will check. Ted Lemon: This codifies existing broken practice without saying "don't do it that way". Using PTR RRs for authentication is not secure, don't say it is. - Peter Koch: So you want to make recommendations, not just considerations? - Ted Lemon: I see the slippery slope. Worried that people will see bad options listed without sufficient vitriol and go implement the bad things. Andrew Sullivan: Still have tire marks from previous reverse tree documents. Don't make recommendations. Can say "there are people who believe these things" and point to some other document expressing opinions on why you shouldn't believe these strange things. We are not going to fix all the broken ideas in this space. Real problem is don't understand what the problem is that we need to solve here. Last time in this shark pool the document was watered down to say "reverse DNS exists" and even that was contentious. Alain Durand: There is value in telling people that they don't have to pre-populate. OK to say just that, plus boilerplate. Operators think they need this permission. - Ted Lemon: Agree with Alain. Just say "you don't have to do this". Why not only document cases we want people to do? - Lee Howard: Can you define what cases we like? - Peter Koch: Can we take this to the list? - Lee Howard: -00 did say "you don't have to pre-populate". - Peter Koch: Have heard "this is good work but what does it mean when a document like this comes out of the IETF?" Is the IETF sanctioning sordid practices? What purpose should document solve? Doesn't mean the document has to go away, but should be clear what statement the document is and is not making. - Alain Durand: What's wrong with and IETF label on a document saying "you don't need to do a stupid thing?" - Peter Koch: Nothing. But if we adopt the document, it should be clear what intent of the document is. - Alain Durand: To give guidance that operators do not need to do something bad. - Peter Koch: A document that lists fifteen ways to shoot oneself in foot could be construed as advising shooting oneself in the foot. - Alain Durand: Agree, remove all of that. - Andrew Sullivan: Documenting all the stupid things one should not do in DNS is a non-terminating task. Chairs will discuss with Lee and make sure we're asking the right question. 5) Current & New Topics 5.1) NSEC3 Hash Performance [Matthijs Mekking][10 min][14:15] Research question: what's worst case effect on validator of increasing the number of NSEC3 hash iterations? The number is determined by the authoritative server but it has an effect on the validator. The graphs shows that increasing key length has more significant effect on validator rate than increasing iterations. With short (1024 bit) keys the effect is significant (cuts Unbound rate by half) but with longer keys the effect becomes less significant. Sam Weiler: Computation overhead is roughly square of key length, this does not show quite that, any ideas? - Matthijs Mekking: Guesses, but not really. Key length has much less effect in an authoritative server (NSD) because NSD isn't signing on the fly. Ed Lewis: What's doing key operations on the authoritative server? - Matthijs Mekking: Hash computations answering questions about nonexistent domains. 5.2) IPv6 & recursive resolvers: How do we make the transition less painful? [Igor Gashinsky][15 min][14:25] At the moment, adding AAAA pointing to production services will break 0.078% of the users, which is about 470K users, which is bad. Alain Durand: We have one source of this number, want better study on this as number may change our opinion on how real this is. - Igor Gashinsky: Ask me again in June, we're studying it. More than 4 second delay on connecting to www.whatever is considered broken in terms of customer experience. Broken here means "These people could reach me over IPv4, turning on AAAA RRs caused them not to be able to reach me anymore". Jinmei Tatuya: What name was this AAAA problem tested with? - Igor Gashinsky: Experimental name within .google.com. A hack is don't give AAAA to customers you think will break if you do so. Specifically. if query comes in over IPv4, DNSSEC not being used, and an A RR exists, say there is no AAAA. This is ugly. May also be necessary. Needs ACL mechanism to give better control. Is this worth pursuing? Should there be an informational RFC? Warren Kumari: Aren't we stuck until everybody implements this? - Igor Gashinsky: Can whitelist. - Alain Durand: This is better than whitelisting. The question is whether price is worth it, can't answer without better data on real size of problem. - Igor Gashinsky: Difficult to instrument to detect the problem, and instrumentation is not going to tell us where problem is coming from. - Alain Durand: Right, all of these all we can tell is that something is broken, so we make a change and hope it will improve matters. - Igor Gashinsky: This is a hack, it's not a DNS problem, DNS is my sonic screwdriver. - Ed Lewis: I have v6 on both ends here this week and still can't get through. This hack would not solve my problem. - Igor Gashinsky: In your case the hack would not be interfering, you might still be broken, but it won't be me that's breaking you. James Woodyatt: Testing for IPv6 connectivity via transport used for DNS is broken. Might be recursive nameserver that has v6 but not the end user. - Igor Gashinsky: Right, this does not hold true for forwarders. So you'd have to implement this hack in forwarders too. - [Missed name]: Solution is worse than problem, need data. - Evan Hunt: it's "filter-AAAA". Not quite in mainline BIND, ISC is not exactly in favor of this. - John Brozowski: We don't love this, but it may be least bad option. We need to understand effects and alternatives. Ted Lemon: You measured how many people would be broken by answering AAAA correctly. You have not measured how many would be broken by this hack. You're adding complexity to solve a problem, that complexity will break other things. Need to do cost/benefit. - Igor Gashinsky: Absolutely. Want to instrument something once we have a second source of data. 6) I/O with other WGs draft-savolainen-mif-dns-server-selection-02.txt Ran out of time. WG please read. 7) A.O.B. draft-wang-dns-newzone-notify-00.txt Ran out of time. Will address on list.