DNSOP WG for IETF 94, Yokohama Thursday, November 5 0900 - 1130 Co-chaired by Tim Wicinski and Suzanne Woolf Minutes taken by Paul Hoffman Minutes reflect what is said verbally, not text on the slides Slides will eventually be at https://www.ietf.org/proceedings/94/dnsop.html Agenda Bashing, Blue Sheets, etc. -- Tim Noted well Question about should 676 bis be done here Paul Wouters: It doesn't belong here Joel Jaeggli: It belongs here, end of discussion Warren Kumari: What is status of alt-tld? Joel: It is waiting for 6761 to finish There are a lot of pieces in flight We need to think pretty hard about the problem Lots of candidates for adoption over the next few months Roadblock avoidance: Wes Haradaker: maybe remove that one sticky bit Hum: is this ready for WG LC? Few in favor, none opposed. Will be demonstrated at Bits and Bytes tonight draft-jabley-dnsop-refuse-any -- Olafur Gudmundsson (remote) Covered use of ANY queries Sorry they earlier proposed RCODE != 0 Don't return big answers RFC 2181 talks about the credibility of the returned data If it would return NXDOMAIN, still do that Cloudflare currently returns HINFO Ed Lewis: Posted comments a few weeks ago Should be adopted, needs to be worked on Needs more justification for architectural reasoning Tim: Hum for adoption Unanimous for 6761 Discussion -- Suzanne This is on our charter The IESG and the IAB want us to do this We have a design team Survey the space and look at what we have already learned Want the design team to be coarse(?) Ralph Droms will lead the team for making progress Not too close to the problem state Ralph: Shepherded 6761 the first time Thinks he can herd cats Just started a few days ago, still in learning mode Suzanne: We have clear ideas about how it will be transparent Not sure how to implement this, but make sure whatever we do is transparent Regular meetings, will post minutes Collection point for the input from the WG Do the work, not make the decisions Suzanne: doesn't have to take time in the meetings, but will do whatever it takes to make progress Information sharing, not just stating views Joel: Wants to channel the concerns we have into something productive Don't want to make a decision for the IETF community Even if we come to some conclusion, that conclusion has to come from the community Andrew Sullivan: This is multiple problems and we're just going to split it up Geoff Huston: confused about the process Ralph: Looking for input, just not at the IETF meetings Suzanne: This has to be an open process We picked a place to start, but that can be thrown out If people want to use WG face-to-face time It as big of a deal now as it was when the IETF did RFC 2860 Suzanne: can use any of the tools needed to make this forward Warren: The chairs asked for volunteers, but we never heard back Is the design team going to grow? Suzanne: the process has not held together well so far Wanted to be sure the work got started Jari Arkko: IESG view is that it is a problem that the IESG should not fix, it should be in the community Should discuss the process Peter Koch: Individual submission How many have read the draft? Many hands go up Illustrate the solutions, show the solution space 6761 executed twice: for .local (RFC 6762) and .onion Should "registry" be checked for every query, once a day, or ... ? What if the registry copy is out of date? Alain Durand: What is between organizations and what is just in the IETF? 2860 gave just examples of "technical", such as .arpa gTLD program at ICANN is aimed at making operational names, not to "reserve" Good time to have a discussion, befor the second round of gTLD program What names are allowed? Could overlap with ccTLDs Potentially offensive ICANN process is heavy and expensive, but IETF has no process at all (currently) 5 possible ways forwards Could be a combination of more than one of the proposals Paul Wouters: If other selectors had worked, we could have used them earlier Ed Lewis: Has a hard time believing that this whole discussion belongs in DNSOP Peter: Have we defined the problem correctly? Stéphane Bortzmeyer: What is the mission of the design team? Does it include suggesting new solutions? Peter: it is allowed but not the prime purpose Andrew: Alain said 6761 extended the definition of what was in 2860 Not sure that is true 2860 says you can ask the IAB Claims that 6761 are not legitimate should not be discussed here Draft seems to suggest that new processes be created That is not a good idea This community uses technical decisions 6761 is not clear enough about whether it is talking about one namespace or multiple namespaces If we clear that up, we will have a tractable problem John Levine: Sees two sets of issues that are not called out .home/.belkin type names that were done wrong vs. .onion This should be separated Warren: Thank you to the authors Doug Otis: History that shows resolution is expected from the right label In the homenet WG, they call this site-local Make sure this doesn't happen in the future Geoff: Draft is light on what 2860 was intended to do Light on analysis of what IANA is expected 2860 gave the entire namespace at the time This draft needs to be clearer on what has evolved and who has what role IETF is not the court of legitimacy for ICANN Can't come here if you have a problem with ICANN Not a pressure release value for someone else's problems For .onion, were we swayed by politics Make this more explicit in the draft It's about the name space Wendy Seltzer: Reminds us that the namespace and application space can use resolution differently Don't add more complexity to the URL spec, please Architectural questions of what applications need to be considered Alain: Does this have to be done at the application layer, or at a lower later Varies by application Stéphane: Wants to see things that are missing in 6761 Formal language so you can extract data from the registry Also write criteria for dealing with an application Measure the use of an application Peter: Did a gap analysis, thinks doing a set of patches on 6761 could be premature Thinks that measuring amount of application usage is not appropriate Alain: If there is no process in the IETF, what should we do? Could possible criteria for IESG Against ICANN-like process Andrew: Doesn't want more analysis of 2860 Chasm from which you will never emerge The problem is where 2860 has exceptions This WG will not have change control over what 2860 says Peter: Where can I discuss this other than in the WG Andrew: Getting rid of 6761 is not in the charter for this WG, but it can maybe do it Don't get into the 2860 hagiography Alain: This document is aimed at highlighting issues, not solving it Joel: Charter asks "What to do about 6761" "We don't like it" is a legitimate answer Jari: Please don't ask 2860 Suzanne: lots of good input, hopefully will have a revision soon draft-jabley-dnsop-ordered-answers -- Andrew Sullivan People are already processing this way for Answer section Not much data backing that assertions David Lawrence: One version of Microsoft software requires the Authority section be ordered Shumon Huque: One implementation requires the order of records and RRSIGs need to be ordered chain-query draft requires some order(?) Order on the wire is different than the order that your application processes them Mark Andrew: Additional section has signifiers for TSIG and SIG0 Paul Wouters: Is the document documenting behavior or dictate behavior Andrew: It clarifies the value of "append" Donald Eastlake: Maybe just say it unordered Thinks the draft is wrong. Hum: Strongly against working on this draft-ogud-dnsop-maintain-ds -- Paul Wouters Warren: Had in 7344, took it out at the time, happy if this happens here John Dickinson: How does parents get NS records? This problem has already been solved. Should not encourage DNS operator to turn off DNSSEC David Lawrence: Big problem is that we are relying on customer to interact correctly with registry is a failure nozzle John Levine: Likes this, has lots of domains he can't get signed Wes Hardaker: Doesn't care about delete Bootstrap based on leap-of-faith affects lots of other stuff such as DANE, SSH fingerprints, ... Might want to put some policy parameters for copying the DS record the first time Paul Wouters: In this document? Yes, as a MUST Ed: For adopting this and then considering what to do Mark: Fix the RRR model Jim Galvin: Cannot do TOFU for gTLDS due to contractural restrictions Hum: Strongly in favor draft-muks-dnsop-dns-message-checksums -- Mukund Sivaraman Roy Arends: You're trying to protect against a second-fragment spoof You can put the checksum there Mukund: already there Stéphane: Just use IPv6 Maybe see what others do in other protocols Wes: Affects every protocol we have We have other technologies that fix this Mukund: We already do additional things for other attacks Because we already use UDP, we need to fix this Peter: Doesn't need a solution here Have other mechanisms already Fears the complexity Not really wrong, but not the right way Hum: Very little for adoption, more for work on it on the list, also lots for not adopting it at all draft-muks-dns-message-fragments -- Shane Kerr Do fragmentation at the DNS layer instead of the IP layer Trying to look like a current DNS message in order to go through firewalls More general than DPRIVE DTLS document Idea: get fewer dropped packets in the future Bits more to do Not asking for adoption at this time, will ask for adoption after -01 Ondřej Surý : Will increase the number of packets Stewart Cheshire: TCP Fast Open mitigates why not to use TCP draft-wessels-edns-key-tag -- Duane Wessels Mark: Send multiple first set but don't merge Also need time windows to hold data be defined Evan Hunt: If the goal is to just to define 5011 compliance, see draft draft-wkumari-dnsop-trust-management Ondřej: Does the cache information count here? Only forwarded on a cache miss Paul Wouters: Why the difference between DS records and cached DS records Could make a target for attack If I have a hard-coded trust anchor, do I really want to tell the world that? Duane: If the WG wants this to only apply to the root zone George Michaelson: This could give us chain lengths as well Ed: Let's adopt this Hum: Unanimous in favor DNAME in the Root? -- Stéfane Bortzmeyer Peter: Possibly a good idea If using root-loopback, would leak queries Olafur: Start writing Andrew: This is toxic NXDOMAIN means NXDOMAIN -- Stéfane Bortzmeyer Especially for empty non-terminals (ENTs) Apparently it is not obvious that if bar.domain does not exist, foo.bar.domain does not exist But it should be obvious NXDOMAIN for a ENT is wrong Paul Wouters: Dangerous idea Hurts if you have a split view defined Ed: Questions about how it works Andrew: Do it John: RBLDNS gets this wrong Shumon: What Vixie's draft is doing is redefining negative caching specifically Supports the draft Makes the resolvers' job harder with NSEC3 Stéfane: Could say SHOULD send it There will be practical deployment problems Giovane Moura: .nl zone has more NXDOMAIN than anything else Tim: Get busy Adjourned