DNSEXT IETF64 Meeting Minutes (draft) Scribe: Wes Griffin Chairs: Olafur Gudmundsson & Olaf Kolkman Date: 2005/Nov/08 Document Updates draft-ietf-dnsext-mdns-45.txt IETF Last Call comments have been incorporated. Chairs will go over latest version and check against comments and then post a summary to the mailing list with a request for review. draft-ietf-dnsext-insensitive-06.txt draft-ietf-dnsext-rfc2538bis-09.txt In RFC-Editors queue. draft-ietf-dnsext-tsig-sha-05.txt draft-ietf-dnsext-dhcid-rr-09.txt draft-ietf-dnsext-wcard-clarify-08.txt draft-ietf-dnsext-dns-name-p-s-01.txt Advanced to IESG, waiting for IETF Last Call. The chairs expect IETF Last Call shortly on most of these documents. draft-ietf-dnsext-nsid-00.txt Passed Working Group Last Call, waiting on write-up from chairs to advance to IESG. draft-ietf-dnsext-rfc2536bis-dsa-06.txt draft-ietf-dnsext-rfc2539bis-dhk-06.txt The documents passed Working Group Last Call, will be advanced. Sam Weiler asked the chairs whether there was any evidence these document had been reviewed. The chairs said that no comments at all were received during the Last Call and the default action to advance was in effect. Thomas Narten feels there is an issue with the default action of advancing work that no one seems to care about. At the end of the meeting (see later minutes) a discussion was held about the default action. The chairs still felt that advancing these specific documents was fine. From the editor, these documents do not change the RDATA format. They only update the specifications to refer to DNSKEY and RRSIG instead of the old 2535 RRs. Additionally, rfc2539bis-dhk updates the list of Diffie-Hellman groups to match the IPSEC DH groups. There are no drafts currently in Working Group Last Call. One draft has been "lost": draft-ietf-dnsext-axfr-clarify This draft will be resurrected by the chairs. There are some drafts that are queued for Working Group Last Call. These drafts have been queued so as not to overload the working group with work. draft-ietf-dnsext-dnssec-trans-03.txt Peter Koch said this draft is ready for Last Call. draft-ietf-dnsext-dnssec-experiments-01.txt This document has been on the table for a while and will be Last Called. draft-ietf-dnsext-ecc-key-08.txt The editor requested more feedback on this document, specifically from implementors. Olafur Gudmundsson asked if the current loose specification for key format could cause interoperability problems? Donald Eastlake felt that implementors are better suited to answer that question. A handful of people in the room have read the draft and one person has attempted implemented it. Ongoing Work draft-ietf-dnsext-dnssec-bis-updates-01.txt This is a running request for implementors to document design decisions and provide input to this document. draft-ietf-dnsext-2929bis-01.txt This document is attempting to address the perceived problem that it is difficult to get IETF Consensus or Specification Required for allocation of new RR Type Codes. The -00 version liberalized the early allocation process and also included a number of other updates to the IANA Considerations for the various DNS IANA Registries. This version met with considerable negative feedback at IETF63. The new version changes the allocation to half requiring Expert Review and half requiring Specification Required. The Expert Review process begins with a DNS RR Type Allocation template being filled out and posted to the namedroppers mailing list for 3 weeks. Rob Austein asked if the latest version had Specification Required for RCODE Types. The answer was yes it does, and he asked that those be removed, as having RCODEs that implementations don't know about is bad. Thomas Narten asked if there were criteria for reviewing new RR Type Codes. He thinks there are a set of valid criteria for determining if new RR Type Codes can be allocated. He will prepare a document discussing these and post it to the mailing list. draft-ietf-dnsext-signed-nonexistence-requirements-02.txt This document has been updated and needs reviewing. draft-ietf-dnsext-nsec3-03.txt See later minutes. Possible New Work draft-andrews-dnsext-soa-discovery-00.txt During implementation of dynamic update clients, it's been found that if a client only has the name needing an update and not the enclosing zone, there is no easy way for the client to determine the zone. Additionally, if the name doesn't exist, there are major negative caching issues with trying to determine the zone. The editor asked the working group to adopt this work. A handful of people have reviewed this document. The chairs asked how many people feel this document is solving a real problem, a few raised their hands. A handful of people said they would review this document. The chairs will propose to the mailing list to adopt it. Interoperability Testing Report Nobumichi Ozoe is part of the TAHI DNS Interoperability Testing project. They tested one DNS client and found some bugs in the client and some bugs in the testing tool. They did not find any issues with the basic DNS specifications. Version 0.1 of the test tool was released 2005/11/01 and is a free download. Current coverage includes the client functionality, basic extensions and TCP/UDP over IPv4. Future coverage will include server functionality and IPv6 transport. The next scheduled TAHI testing event is end of January 2006. There is now a mailing list: dnstest@tahi.org and interested people can subscribe via dnstest-ctl@tahi.org NSEC3 Report and Discussion There is an issue tracker available for NSEC3: http://nsec3.nominum.org.uk/ Issues, both open and closed: Issue 1: Signaling NSEC3 to NSEC3-unaware resolvers. Mark Andrews strongly objected to a flag day and so we need signaling. Ben Laurie answered that if we're going to do signaling, we need to decide how to do it. Issue 2: Transition from NSEC to NSEC3 by being insecure is fine. Issue 3: RFC2932 Base32 encoding is used to solve the sort order issue. Issue 4: NSEC3 hashes have owner names whose existence is denied. No one has yet to present a technical argument on how this is a problem. Peter Koch felt that we don't know yet whether this will be a problem and as such we can't summarily dismiss it. Especially considering we have a precedent of ignoring "problems" that have come back to haunt us. He has half-seriously proposed on the mailing list a solution involving using a new label type. Olafur Gudmundsson felt that we should do some experimentation to better determine if this will be a problem and keep this issue open until then. Olaf Kolkman said that the working group has agreed that for this document, it will not proceed until and engineering workshop has occurred and code has been tested. Ben Laurie stated that there are 3 implementations close to being completed. Ed Lewis said he won't consider this issue closed until he sees it in working operation. Russ Mundy said he wants the working group to figure out a way we can move forward. Mark Andrews stated that there is a way to do this that will have zero impact on the namespace of the zone. Issue 5: NSEC3 hash name and legitimate zone name collision is okay. The editor believes this is not an issue. Rob Austein said that he's 3/4 close to leaning towards Peter Koch's half-serious new label type proposal. He feels this is a much cleaner solution to all this collision stuff and has the added benefit that it can be defined as a binary-only label type which removes the sort order issue as well. Ben Laurie asked how this would interact with caches that don't grok the new label type. Rob replied that dnssec-bis doesn't work through dnssec-oblivious middle boxes, so this might just be a non-issue. Paul Vixie stated that the original idea behind the separate label type was to provide a way to store the various sets of metadata that aren't truly dns data and hence don't really belong in the actual database proper. This data we're talking about here is also not dns data and so a separate label type would go a long way to helping this. Ben asked if people were okay waiting until implementations were done before deciding on this. Issue 6: There is a potential DoS attack on resolvers. Evil editoritative servers can select such a high number of iterations that resolvers are overwhelmed. The proposal is to allow resolvers to specify an upper limit for iterations that it will accept and if a response has a higher number the resolver will treat is as bogus. Olafur Gudmundsson asked why we can't get rid of iterations and just use the salt. Ben explained that the iterations are designed to increase the cost of a dictionary attack, while the salt is used to increase the cost of a pre-computed dictionary attack. Olafur rephrased his question to is the salt sufficient for the threats people are seeing? Ben feels this is no, as a single iteration is very easy to handle with a network probe. Olaf expressed a concern that leaving this up to resolvers will cause some resolvers to set a low number and some a high number causing a zone to appear secure or bogus to different resolvers. Ben answered that by picking a sufficiently high number this shouldn't be a problem. It should be a single number and not in the draft. Mike St.Johns said that if a number is going to be chosen, please put it in the draft and be nice to implementors and users, don't make it configurable, just set it across the board. Ben says if the working group feels strongly about this it will be done. Someone asked if a mechanism could be added such that parent zones can set limits for the iterations. The room response was highly negative. Issue 7: How secondaries know the NSEC3 parameters a zone is using. The solution is that any parameter set present at the apex will be present in the entire zone. Issue 8: The next version of the document will include additional detail about the design choices and rationale. Issue 9: The next version will have the hash algorithm field set to 8 bits so that it can share the hash algorithm registry with the DS RR. Sam Weiler asked about his proposal to get rid of the algorithm field in the NSEC3 RR and just inherit the algorithm used by the DS RR. Olaf Kolkman asked how this would work if there was no parent. Mike St.Johns asked what if a zone is using multiple hash algorithms. Trust Anchor Management Reports and Discussion This space is rapidly growing with drafts and there has been very little review by non-involved participants. The chairs urge the working group to pay attention because this item is very important to deployment. Current Work: draft-ietf-dnsext-trustupdate-threshold-01.txt A co-editor stated that this update was primarily to boilerplate to refresh the draft so that it would be available for consideration. A prototype implementation is currently being worked on. This and the following 2 drafts have IPR claims on file with the IETF. The co-editor stated that he's been working with his university lawyer and can proceed on a prototype implementation. He expects it will be ready by the end of the year and will make it available to a select group of people who will not be affected by the IPR. draft-ietf-dnsext-trustupdate-timers-01.txt The editor said this version is almost a boilerplate change to refresh the document. He has started an implementation in dnsjava. draft-moreau-dnsext-takrem-dns-00.txt draft-moreau-dnsext-sdda-rr-00.txt The author presented slides on some basics of trust anchor management including some discussion of requirements and how the TAKREM proposal works. Ben Laurie asked why, since emergency key rollover doesn't depend on key revocation and there will be some other mechanism to do revocation, why not just use that? Mike St.Johns asked about how previous keys are revoked. The author said the TTL would revoke the keys, it was pointed out that there is no built-in lifetime on keys. He said this would be addressed. Bill Manning asked about one slide bullet that said change control had been handed over to the IETF and if this meant the IPR claim no longer applied? The author said no. Steve Crocker said it would be much easier if the technology was unencumbered so that we could get on with implementation and testing. The editor said there was already an licence for GPL implementations. Ben Laurie, Paul Vixie, Matt Larson and a Cisco gentleman all said GPL was insufficient for their needs. Olaf Kolkman summed this as a requirement for the trust anchor management requirements document. The author stated a requirements document by the working group would be useful. draft-laurie-dnssec-key-distribution-00.txt The author said the original idea behind this proposal was to do it with x.509, but that x.509 has some issues with cross-signing and so a future version will use PGP signatures. This is the only proposal on the table that has no known IPR issues. Bill Manning asked about what transport this will use, as the user is expected to visit a URL and follow a signature chain. His concern is that the end-to-end assumption is increasingly wrong. Also, how does the proposal cope when data can't be pulled from the URL? The editor responded that http is the current transport, but really anything can be used. Also, the data can be pulled from any location so this shouldn't be an issue. Russ Housley asked why this is solving the problem, as he thinks it doesn't. Also, this looks exactly like what x.509 was designed to do. The author said that x.509 doesn't support multiple certificates with the same DN, Russ said it did. Michael Richardson asked if there could be some sort of cross signature threshold mechanism added so that resolvers only trust what's going on when there are a minimum number of signatures. The author said that this proposal was such that if a resolver trusts a zone, then it trusts what the zone signs (and cross-signs). Paul Vixie: Simple Key Rollover All of the current mechanisms seem overly complicated. This method: Adds a new zone apex RR that expresses H(keyset). This is included in the authority section in replies. Interested validators can track this RR. When it changes, the validators can fetch the new keyset. If the new keyset validates it becomes the new trust anchor. Interested validators can also pull. This pulling is based on the half-life of the current keyset signature lifetime and the half-life of the current keyset TTL. The pulling is obviated by the new zone apex RR if seen. This new zone apex RR is an opportunistic optimization. This differs from the N-of-M proposal: N is now a per-algorithm constant, and 2 seems to be fine. Removes a policy knob from the client. The new zone apex RR trumpets new keysets. Most validators won't have to pull. Revocation is by omission only. It is always good to have more than one key. This is very lightweight, but doesn't solve emergency rollover. Puts most of the policy on the server-side. Validator policy is simple. All a validator does is track static configured trust anchors. Possible Server Side Policy: Never use a key without also publishing the next one (or the next several). Never use a key without also publishing a backup at the same time (for revocation purposes). Overlap current/next key lifetimes by 50%. Start using a new key at the second half-life (25% remaining) of the existing key. Roy Arends asked why we need to add a new zone apex RR, why not just publish the keys? Olaf Kolkman responded that there are size issues with publishing all the keys. Ed Lewis noted that while server side policy may not be an issue, DNSSEC has always been about the view of the DNS at the resolver. General Discussion: Margaret Wasserman stated that all of these mechanisms appear to be very different in everything that they're trying to do. For example, do we have consensus on needing emergency key rollover, or do we have ideas on requirements or threat models? Olafur Gudmundsson asked what do we have to do with trust anchors? For example, should a trust anchor management protocol be able to turn off DNSSEC for a zone? We need a better handle on the key rollover requirements. Olaf Kolkman stated that this work has come up through the mailing list and the solution space is expanding without the working group knowing which metrics we want to apply to make a choice. He asked for a volunteer to start a draft outlining the requirements. He also asked if this is work that interests the working group. If there is no work currently being done in the working group do we care about the work? A room hum is overwhelmingly in favor of the work. Olafur says we need volunteers to work on requirements, review documents, and do work. The chairs will ask on the mailing list for a deadline for requirements being done. Thomas Narten is troubled in that there seems to be some sort-of interest in this work, but the work itself is not getting done. Perhaps the wrong questions are being asked, how about asking something like "What are our 3 top priorities, the 3 most important things to get off the table?" Ed Lewis stated that as a consumer of an ISP, I don't care about what keys zone operators are pushing out, but I do care about my ISP and what keys they are using. Olaf felt that we can't make further decisions here on a way forward. We need requirements and metrics on what is sensible and what the group wants. Default Action For Document Review Discussion The chairs ask if the best way to handle review is to set a lower limit, on the order of 4 or 5 people, that must review a document before it is advanced. The room hums consensus. Peter Koch asks what will happen if the document doesn't reviewed, will it get dropped or will it remain on the work items list indefinitely? The chairs state that the document will be dropped and authors will have to do a personal submission. Sam Weiler asks that before the drop occurs, we keep it as a work item and have a review by name and then if there is still no movement, drop it. Priorities The chairs see 3 major work items: NSEC3 Trust Anchor Management Work dealing with forwarding documents along the standards track This includes rewriting any documents that need clarification. The chairs ask for a hand show of what is more important: NSEC3: 10 TAM: 15 The chairs asked if there is a reason we should NOT do this work in parallel? Sam Weiler said that as long as there is a critical mass of people working on each item, then we should do the work in parallel. Thomas Narten mentioned that even thought requirements documents have bad reputations, without them, important discussions are often side-stepped and not resolved. The requirements documents should be short-fused, if one cannot be completed in 3 months, the work has a serious problem. The chairs responded by saying that requirements are needed, and if the requirements are not completed in a timely manner the work will be dropped.