IETF 65, Dallas, Texas 2006-03-21 1900 UTC DNSEXT WG Minutes - The biggest darn WG in Texas. *) Introduction http://tools.ietf.org/wg/dnsext - Olaf thinks it's cool. 1) Agenda Minutes: David W. Hankins Jabber Scribe: Mark Andrews xmpp:dnsext@rooms.jabber.ietf.org Previous Minutes - Chairs asked for comments. - There was no comment. 2) Documents Status: o CERT RR bis - draft-ietf-dnsext-rfc2538bis-09.txt - Proposed change. - Olafur noted people had until today to comment. - No one has commented, therefore it will be accepted. - Expect this to go RFC soon with this change. 3) Documents Advanced: DS-SHA256, document is through the IESG. Wildcard Carify - Finally coming to a conclusion. - A few comments during IESG review. - New version addressing the comments has been submitted. Expect it to go straight to RFC editors. DHCID - Hopefully this will be the last time Olafur will have to talk about this document. It has been around since he started co-chairing. No new controversial changes, it should be done, new version needed. NSID - Slight delay until the new AD is up to speed, then chairs will ask for IETF Last Call. LLMNR - Requested to be published as informational. - This is interesting and important work and it should get published. Chairs: We want to say 'There was insufficient feedback to determine consensus.' Please give us feedback in the future. Last call completed, waiting for chair: draft-ietf-dnsext-rfc2536bis-dsa-06.txt - These documents were in WG last call at last IETF. So far we have not received sufficient feedback to meet the minimum review requirements that have been imposed. - People need to review these documents. - Otherwise, the chairs will be forced to kill these documents. Request for chairs to list people that have reviewed the documents - Several people raised their hands to volunteer. draft-ietf-dnsext-rfc2539bis-dhk-06.txt This has the potential to make tsig use simpler. If anyone in here is willing to review these documents in the next few weeks, that would be great. Volunteers: Ben Laurie, Jeff Sissens, Sam Weiler. Mike St. Jones. Drafts pending last call. DNSSEC experiments documents are in last call, the consensus is that both documents should be forwarded modulo small text changes. Evaluating DNSSEC in last call. The editors were going to make some changes but didn't do them, we are still waiting. Elliptic Curve Keys in the DNS. There has been very little input on it. Is the format suitable for interopable use? Olafur wants feedback from CFRG on what the group should be specifying. Olafur will raise with the SAAG in the future, and hopefully we will get some idea what this document should be encompassing. Karl: There should be some predesigned standard abbreviations for certain parts of elliptic curve. If he can do it, he will rev the draft and put that in. We will keep this draft for a little while longer. This is also a document that will need to have sufficient people reviewing it before it can be submitted to IESG. Further motivation: Elliptic curve keys are very small compared to RSA keys. If this gets into wide use, it will make dnssec packets quite a bit smaller (both sigs and keys). Verification is more time-critical than signing. Is Elliptic curve a good fit then? Ongoing Ben will rev signed-nonexistance-requirements so it becomes current. nsec3 specification got updated. There is going to be a workshop before the next meeting to address issues. Stay tuned. RSA/SHA256 Algorithm - the chairs have commisioned a document, they are not sure if this is strictly needed or not or if it should be done just to have it around. Please look at the document. Will move forward or drop it based on feedback. Zombie axfr-clarify This document, a long time ago, got stuck in limbo basically because it became too hot and nobody wanted to touch it, but the chairs are going to try and take it back, solve the issues raised and so you should expect discussion on this to start next month. == NSEC3 Status and Issues - Geoffrey Sisson When asked who has read NSEC3 drafts, approximately half of the room raised their hand. Geoffrey stipulates we may therefore be able to have a useful discussion. Geoffrey next asked who expected to come to the NSEC3 workshop in Frankfurt, approximately 25% of the room raised their hands. If you could let him know individually wether you're coming or not, as soon as possible, it would be very helpful for planning. It is not an IETF sponsored event, it is a sort of a code bakeoff, but the experience from that - showing lack of specifications - that will be fed back into the IETF. At IETF 64 many NSEC3 issues were reviewed, then discussed on namedroppers. Some were resolved, probably hard to have missed that on the mailing list. Some new issues were identified, some that we talked about in Vancouver had fixes for. The current list can be seen at http://www.nsec3.org/ The main idea is to get people with implementations in the room, and to let them fight it out. To find all the corner cases and cover them. The hidden objective is if we can avoid it at all to have a second Workshop. This is scheduled for May 8-10 at DENIC in Frankfurt. A "pre-workshop" was held at Nominet on 6-8 March. http://www.nsec3.org/cgi-in/trac.cgi/wiki/Workshop0 The latest draft, was submitted two weeks ago, and there's another new draft to be submitted shortly with changes determined in the pre-workshop. That hasn't been submitted yet, but can be got at the below URL. http://www.nsec3.org/draft-ietf-dnsext-nsec3-05pre1.txt All known NSEC3 responses/validations are enumerated. Several clarifications. Working code: NSD 2.3.3 patches by Ben Laurie. Fully nsec3 compliant as of pre-5 draft. Two signers, one written in perl by Roy Arends (pdnssec-signzone) and one written in Java by David ZBlacka (jdnssec-signzone). All available on the nsec3.org website. Unbound includes NSEC3 recursive validating resolver. Also, there are some dig 9.3.2 patches by Ben Laurie to make it understand the NSEC3 typecode (doesn't validate/sign). Closed Issues - Use of hashes creating new owner names. It's true, new names are put into the zone for nsec3 records that weren't there previously, in contrast to dnssec. But Geoffry thinks everyone agrees, other than a few corner cases, that this doesn't represent any serious issues. - Peter thinks the so-called 'Paradox Problem' is still an issue. Geoffry agrees, but that's covered later on. - RFC compliance with BASE32 encoding, but as it turns out this encoding wasn't as intuitive and was pretty ugly so they decided to use the same ordering as in rfc2938. - How do you determine what the correct zone parameters are? A nameserver with a zone knows how many iterations and what salt to use when creating hashes and names. Right now, there's no obvious internal way to do it. There are a number of records there may be more than one NSEC3 chain in the server, they may be complete or incomplete. Without putting it in an external configuration file there's no way for a server to know which set of those to use. This is for authoritative servers. The case that best illustrates the problem is the case of a secondary that gets a zone transfer, is presented with a zone, and doesn't have any obvious knowledge about how many iterations of which salt to use when hashing. Solution is to make the one NSEC3 resource record in the zone that has the SOA bit set (there will only be one). Olafur: How does an authoritative nameserver find that record if it doesn't know the iterations or the salt? Geoffry: It has a choice. In the case of a database backend, it could it could look at all the NSEC3 records and look for the one with the SOA bit set. But that can be very expensive. That can be simplified by adding meta-data, say an additional column. Olaf: Is it required that the SOA record always have the record? Geoffry: Yes, you can't opt-out the SOA, only delegations. Even though it's a closed issue, there is some discussion, right now this is sufficient, and we can't see any implementation issues about it. One problem is that it would be nice if there was more information about design rationale. That's been provided in -04. It will be further expanded in -05. Maximum Domain Name Length. Longer hashes mean shorter names are required in order to fit. This issue is resolved by admitting such problems are unlikely to manifest in ways that affect users (label length equal to 255 is unlikely). Potential DOS on Resolvers. Resolvers have to do a lot more work, other than just doing validations. They have to do iterations to make sure the records they got back agree to construct the non-existance proof. They have to do a lot more work than a normal DNS resolver does, so that means you can send relatively few messages to a DNSSEC3 resolver to cause it to exhaust its resources. Approach the IETF Security directoriate to establish an upper limit on iterations. Because theoretically someone could create a set iterations so high a single query would fully monopolize the resolver. Potential DOS on Servers. Similar problem. We think currently that a sufficiently provisioned server that there should be enough power to do that. That essentially you could saturate gigabit or higher links to it before you would exhaust the server. Olaf: Why do we need the iterations field, and why are we doing this? Is this strictly necessary? Geoffry: Yes. We wanted to make an offline attack as expensive, or more expensive, than an online attack. Eg a dictionary attack. One potential attack is that you can basically walk the NSEC3 chain and then proceed to...offline, with great efficiency (no intermediate network) to just brute force iterations. With iterations, that makes that sort of offline attack at least as expensive if not more expensive than trying to do the same thing on-line. Roy Arends: The question of having an iterations field in the NSEC3 rdata is not an issue, it's in the requirements document, so it's a closed issue. Olaf: ... I want to ask the question not to break open what we've discussed before, but was wondering maybe if you look at the issues presently on the table, two real operational issues, then the question is 'maybe you guys feel the pain when looking at this...maybe you make a different tradeoff between the work done offline and the work done online when serving the data.' The economics needed for the attacker vs the econmics for the bonified clients and server to do the work. Ben Laurie: If the zone does not care, it sets iterations to zero, and then it will do one hash. Olaf: But that doesn't say anything about the previous issue that if the not-so-bonafide sets his iterations to 30,000. Ben: Which is a DOS on resolvers, which is why we propose an upper limit so they're allowed to say 'if there's too many iterations, give up.' Sam Weiler: Are you asking us if we should drop iterations entirely? Olaf: I was asking "what are the arguments for the tradeoff"? Sam: I'm happy to leave a feature in NSEC3 that will discourage people from deploying it. Discussion was terminated at this point. Queries for NSEC3 RRs. The resolution to this issue is under question, that discussion will be taken to the list. Geoffry: In considering non-existence proofs, you actually get into a very non-intuitive set of issues, but it does actually work out so far as we've been able to determine...these things are logically consistent, it just is not what you would expect. It's something that you can't rely on in a mental;/intuitive model, it's something you really need to think trhough. It's possible to determine if an NSEC3 has been stripped by a man-in-the-middle. It does take serious mindbendingly immersive observation of the document to understand this. There was discussion about what happens if the NSEC3 QNAME is stripped. Mike St. Johns: This is a corner case of the whole thing. NSEC3 RR owner name coincidence It's possible for NSEC3 RR and other RRs to have the same owner name. You'd have to be extraordinarily lucky if you happened to have something that looks like it could be a 32-octet hash, and then you got an nsec3 owner name that coincideded exactly with that. What could happen, is somebody could, once the zone had been signed, then introduce a name with the nsec3 owner name, and in looking at all the possible consequence of this, what they decided is that no special processing was required. You would get a strange result when you query for that name, but it wouldn't actually break anything. DDNS and Opt-In Determination. It's unclear, with opt-in, without providing additional information wether an update of an insecure update is to be included as an opt-in delegation, or a non-opt-in delegation. We go into some depth on this on the mailing list, and right now we really don't have an answer on how we're going to deal with this. One method might be if an update happens on an opt-in span, just to put that unsigned delegation into it, and if it happens on non-opt-in, then you would insert that into the nsec3 chain. But that doesn't give you full control over the contents of the zone. It's a bit strange. Olaf: You would have to have a key online, which is not a requirement. Geoffrey: That's true of dnssec as well. Closing. Peter: If you need any travel advice or logistics help contact Peter Koch or Geoff. After the workshop in May, we hope that the work from that will result in a final document. Steve Crocer: What's the delta between that workshop and the cutoff for submission of drafts for the next IETF meeting? Geoff: The cutoff should be end of June. They'll have about a month. Steve/Olaf: It would be nice to have the final version before that cutoff. Russ Mundy spoke about Key Rollover requirements. We've got a number of proposals on the table talking about how trust anchors will get roleld over end resolvers. Most of the WSG seems to agree that something like this is needed for the successful deployment of dnssec. With the proliferation of authors, people observed that they were each trying to solve different problems. So we need a requirements document. There were a couple requirements that seemed pretty clear, but largely the quantity of requirements that were identified in Vancouver was very small. The editors have a gfew ground rules. Do the best we could to to be independent of the actual solutions. Not include any of their own requirements (so if no one gives any to them, it doesn't go into the document). Very few requirementss inputs were produced after the meeting. They only got input from 3 sources, that was it. The quantity of requirements is very very small. Only 10 identified explicitly in the first -00 draft. Two documents have been published as ID's. There's been some very lively discussion. - 10 requirements identified in WG ID. - 100 messages to namedroppers since announcement of ID. - 90 of them on one particular issue. Bill: I would like to point out there was possibly another submission given to the editors. Russ: And there was an offer of a fourth. Bill: One editor suggested that my requirements submission was overly broad. Bill's discussion was tabled. Russ: Following mailing list, 'No Intellectual Propery' words is closed. Olaf: Can I have a hum from people in the room who have read the topic 'Re-Issue' with proposed text from March 16? Who read that message? A fair number hummed saying they read it. A fraction hummed saying they agree. No one hummed saying they disagreed. The Ten Requirements were enumerated for the WG. 5 look OK, 2 are OK but need detailed work, 3 appear to need closer look at as requirements themselves. Some feedback so far is that "Definitions contain embedded requirements" - We think this is largely due to the small number of requirements we were given. Please send us text. Fundamentally the desires of the WG are not clear. We will publish an 01 version that incoproates current changes. Hopefully by the end of next week. If we're going down the wrong path today, I want to hear that today. We need more input, what do some of these requirements mean? Please provide input, let the editors know. Olaf: I wouldn't like to beat this baby to death over half a year. I would like to see it be reasoanbly ready in the next 1-2 month. We said that before...I hope the editors can commit on fast cycles. I also hope the group can commit on fast feedback, on the list, as patches to the current document. That is most productive. If you have something you want to change, send text in the form of a patch. Olafur: In particular, before russ and his co-editors crank out the next version, are there any requirements you see that should be in there? Mail them out now? Any comments on this draft? Olaf: There's another thing I want to say, this should not be common dogma...this is not a dogmatic requirements document. Bill returned to unshelf his issue. Bill: This document does not meet my idea of what requirements are. I've submitted some text and been told that it is overbroad and overreaching. What Bill thinks of as are requirements is different form the editors. He would like to sit down quietly and beat them with sticks. He is not going to hinder this document to proceed, but it doesn't meet his requirements. Olaf: Previously we asked you to contact the editors off-list so they could prepare a version 0. Now this is a WG document and the WG has control. Whatever you discuss in the hallway is not my problem, but if it needs to go into the document please send it to the list as a patch as part of the normal process. Russ: This particular document is looking at a particular aspect of what is happening in DNSSEC, not the overarching requirements in DNSSec, just that one particular piece. Olafur: If members of the WG are having problems with editors of any document in the WG, please bring those issues to the chairs. Whenever you submit something to any editor offline, CC the chairs. Olaf: Any more technical points? Mike: The DNS System has a limited lifetime for any of the information in it, and it's refreshed at the resolver with queries. It's unclear if you're going to build a protocl that works inside or outside the DNS protocol, what that lifetime is, and wether you put the requirement on the resolver to save its state of however many days and live through a down point. It may be that when you get to the analysis that when you look to do something inside the DNS protocol it just may not be possible to do whatever a particular zone provides. Russ: From a requirements document point of view, there has not been an explicit decision been made wether it would work inside or outside the DNS protocol. What does the WG believe is the proper way to state this requirement and the duration? Mike: This is one of the few requirements on the list, in fact maybe the only, that if the number is tweaked wrong it will absolutely prohibit the in-DNS solution set. Donald talks about 2929bis. He believes it is converging. 2929 provided reasonably complete IANA considerations for DNS protocol values. The problem was that it was felt, particularly for typecodes, that consensus was too hard to get for timecodes to be assigned. So it led to overloading of TXT field and so forth. So it was decided there would be a liberalized version of early-allocation in RFC2929. However, at the Paris meeting there was a huge backlash against this highly tweaked 'early allocation' and a call for 'expert review' resulting in draft -01. In Vancouver, this was more favorably recieved by the WG, but it was felt there should be more explicit guidance on what things require expert review and what requires WG consideration. draft-ietf-dnsext-2929bis-02.txt will be submitted next week. All changes are described in the Appendix. Expert Review is now only available if a DNS RR Type Allocation Template has been posted for at least three weeks on the namedroppers mailing list. The data type must be either a type which can be handled as an unknokwn RR as described in RFC3597 or a meta TYPE for which processing is optional, i.e., which it is safe to simply discard. The 'Type Parameter Allocation Template' was displayed. Peter: I agree I don't see a major prolblem with most of the proposals for types that just try to be a container for random data, and this is fine. But there are a number of proposals and usually when WG use protocols that use DNS not only specify a certain record type, which is just a data container, but they also require certain handling, and that certain handling can or can not be like tree climbing or making assumptions about inheritance that is not present in the DNS, and so forth. The special handling affects the DNS, and this is the concern I have. You can of course handle these record types transparently within the server within any resolver, however the application may try to walk the DNS tree and this has operational consequences at least. I am not sure what to do here. I am trying to advocate for a more thorough review. To look into the application use of the RR type in that particular protocol. Donald: I think that's pretty reasonable. I guess the hope is that the expert is able to do that. Also that if it was posted on namedroppers for 3 weeks that someone would comment, and that the expert would be someone who reads namedroppers. Peter: I didn't suggest that everything has to go through standards track, but the question is how tightly the expert is bound. If the expert can only reject or recommend against based on either it not being a simple type or a nonmeta type, then we might get into trouble. Olaf: There seemed to be in Peter's suggestions a specific set of instructions for the expert? Peter: You are asking me to volunteer to do something? Sam: I suggest we keep roughly what we have, which is half the space for IETF consensus, half the space for specification required with expert review, and provide a template to do that. Donald would like to solicit feedback. He feels he is getting closer to consensus, but he thinks it's also a moving target. Mark: Just got done getting DLV out the door. We actually need guidance from the RFC editor to come out of these sorts of processes, because things in there can just bounce straight back out. The RFC Editors process does not work sometimes. Yukiyo Akisada presents the DNS Conformance Tester report from TAHI. Tester status: After 1 year of development, version 1.0 has been released. You can download it at http://www.tahi.org/dns/ DNS Server and Client support, IPv4 and IPv6, and both TCP and UDP transports. Currently they have 270 users. "Please use it more." An example test for caching query was presented. The tests between client and server, server and server, and server and client are all observed and verified. The result is an HTML display of all test results. At Nippon Convention Center, they held an interoperability event. They were able to test one DNS client, and found some SHOULD violations. They hope more people will come to the next event. http://www.tahi.org/ contact@tahi.org dnstest@tahi.org Olaf: In writing a test suite you must have found some different interpretations of reference. Yukiyo: Indeed, and we mention these on dnsext mailing list or bind-users (presently the test suite is bind specific) depending on a case-by-case basis. Russ Mundy speaking on NSEC3 validation. Empty non-terminal no-data response. Name exists, but is empty. RFC4035 specifies this as an error. Rob: I think there's some confusion here. This specification does not talk on the existence or non-existence of names...they only talk on the existence or non-existence of rrsets. There is no difference between a couple of the cases Roy is talking about here. Russ: We'll talk about this on the mailing list. Russ will sit down with Ralph and Sam and try and get words in there to fix these issues. Olaf: Do you think these are implementation things you have to consider, like is this a checklist of things you ahve to implement, or is this really specification or protocol bugs? Russ: Going down that list is definitely not a protocol bug. This is just stuff that we found during the nsec3 workshop that we noticed are not in the 4035 drafts. You really need to check these things if you're making your own implementation. Mark: I think basically all these are covered, but these are things you just need to be careful of. As far as my memory of reading 4035, it's all in there. It's just implementation care. Russ: I've been going through the RFCs, and it's not in there. I thought it was in there, but wasn't able to find it. Geoffry: It's a specification bug, as I understand it. It could be fixed with one sentence in the specification. Someone could implement a 4035/4033 validating resolver and get this wrong. Olaf: It sounds like this updates 4035. Can you make these separate issues and send them separately to the list? Russ: Sure.