Minutes for DNSOP at IETF-94
minutes-94-dnsop-2

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
        <slides go here>
        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