Minutes IETF111: dnsop
minutes-111-dnsop-00

DNS Operations (DNSOP) Working Group
IETF 111, virtual instead of San Francisco
Chairs: Tim Wicinski, Suzanne Woolf, Benno Overeinder
Minutes taken by Paul Hoffman
Notes here do not include material from the slides
        Mostly comments on presentations
About 110 people in the meeting

Session 1, 2021-07-26

Administrivia

Current WG documents

Guidance for NSEC3 parameter settings, Wes Hardaker
        draft-ietf-dnsop-nsec3-guidance
        Jim Reid: Would rather be based on measuring effort needed by resolvers
        instead of just existing practice
                Wes: Would need to understand what the impact is for high values
        Viktor Dukhovni: Had an off-list discussion with vendors on Jim's
        question
                The spike at 100 will disappear in the near future
        Wes: A number of people want 25 or 50
        Ulrich Wisser: Why go insecure? Why not SERVFAIL immediately?
                Wes: At least allow the request to go through
                Viktor: SERVFAIL has merit, but might might break things
                without easy resolution
        Jim: Maybe use error code to say why response was insecure or SERVFAIL

Glue is not optional, Shumon Huque
        draft-ietf-dnsop-glue-is-not-optional
        Duane Wessels: "All glue" is different than the way that authoritative
        servers today Geoff Huston: Why is sibling glue mandatory?
                Not sure that sibling case justified
                Mark Andrews: Can also get delegation loops with sibling glue
                Geoff: Put that statement in the draft
        Ralf Weber: Would rather not have this be a MUST
                Could open to Kaminsky-style attack, causes more data
                Shumon: Not imposing on resolvers, only authoritative
        Peter van Dijk: .com/.net do not do sibling glue today
                Please add an implementation section
                Shumon: Corrects Verisign setup
        Ulrich: Orphan glue is a security risk
                Shumon: Wants agreement that this could be discussed
        John Levine: Glad about the "all" glue point
                Don't add distractions with sibling and orphan


Fragmentation Avoidance in DNS, Kazunori Fujiwara
        draft-ietf-dnsop-avoid-fragmentation
        Paul Hoffman: Not giving a suggested value goes agains Best Current
        Practice Viktor: Is it sufficient to set "don't fragment" on the client?
                Maybe the attacker can fragement
                More detail would be great
        Paul: ANRW attack is about .5%
        Viktor: Would like a set of appropriate practices

Revised IANA Considerations for DNSSEC, Paul Hoffman
        draft-ietf-dnsop-dnssec-iana-cons
        Suzanne: Registry policy is uninteresting but has long-term effects
        Viktor: Old GOST algorithm is long-obsolete

Other drafts of discussion / New working group business

Survey of Domain Verification Techniques using DNS, Shivan Sahib
        draft-sahib-domain-verification-techniques
        Viktor: There is an obvious attacker-in-the-middle attack
                How do we scope this properly?
                Wanting to prevent challenge replay
        Donald Eastlake: There is already a registry for underscore names
                Shivan: Wants to use that for this use case
        Ben Schwartz: Supports this, wants more security attention
                Could trigger RR parsing bugs
                Could trigger wildcard bugs
                Some forms have predictable QNAMEs


DNSSEC automation, Ulrich Wisser
        draft-wisser-dnssec-automation
        Brian Dickson: GoDaddy is interested in supporting multi-signer
                Also want to support CDS/CDNKEY through EPP
                Also interest in bootstrap
                Ulrich: Bootstrap can establish initial trust between signers
        Shuman: Bootstrap document is interesting and should have more
        discussion in the community Suzanne: Not trivial to implement
                Wants to see interoperable implementations on the horizon
                Ulrich: Currents with PowerDNS, working in BIND; this, soon
                        Wants independent service providers on board

DNS Access Denied Error Page, Dan Wing
        draft-reddy-dnsop-error-page
        Ben: This is aimed at browsers, but the browser vendors criticism have
        been ignored
                Would want to see implementation interest before moving forward
                Dan: Next draft deals with this

Structured Data for DNS Access Denied Error Page, Tirumaleswar Reddy
        draft-wing-dnsop-structured-dns-error-page
        Ben: Is an improvement, still has concerns
                Name in structure is not authenticated, URLs are not
                constrained, lots of pitfalls Would prefer no URLs, not
                intended to be shown to users Would like to harmonize with HTTP
                response code 451 Indirection through HTTP is complicated and
                unnecessary; won't work without an HTTP stack
                        Dan: Categorizing is hard
                Some of the language here normalizes DNS response forgery, not
                acceptable
        Viktor: Make the responses as compact as possible
                Some resolvers are doing DoH on behalf of user: should errors
                be cached and returned from cache?
        Warren Kumari: Needs to be coordinated with SECDISPATCH and maybe TLS
        WGs
                Be careful that this does not normalize DNS filtering
        Vittorio Bertola: Better than unstructured one
                Why use indirection? Just use DNS reply
                Could just use hooks
                Will never get agreement on whether DNS filters are good
        Jonathan Reed: Could minimize responses by getting rid of cause of error
                Reality is that DNS is a control plane
                Wants to see filtering normalized
        Joey Salazar: Agree with Jonathon
                Will get people agreeing on concerns, particularly about misuse
                Doesn't see how this would normalize censorship, would help
                informed consent
        Andrew Campling: Agrees with earlier on this being positive development
        for user experience Paul: This is not simple
                We can make a bad thing easily
        Warren: Agrees this is much larger
                Questions whether documenting this will be seen as endorsing
                censorship Creates an attractive nuisance
        Andrew: Not helpful to use terms like "DNS censorship", many people opt
        into DNS filtering
                Surely this useful to help bring it out in the open


Session 2, 2021-07-29

Empty Non-Terminal Sentinel for Black Lies, Shumon Huque
        draft-huque-dnsop-blacklies-ent
        Peter van Dijk: Should be documented
        Joe Abley: Thinks it shoudl be documented
        Paul Wouters: Agrees
        Shuman: Cloudflare is on board with renaming and publishing
        Donald Eastlake: Requires a standards option to get IANA allocation
        Brian Dickson: Is this for NSEC3 or just NSEC?
                Shumon: Just for NSEC
        Shane Kerr: No benefit to use NSEC3
                Wants this to be a WG item so it can be fixed up

Liaison reply ISO 3166-1 user defined codes for draft-ietf-dnsop-private-use-tld
        Suzanne Woolf gave presentation from chairs
        Joe Abley gave presentation from the document editors (just the last
        slide) Viktor Dukhovni: Has thoughts on how to find things that are
        safe to use
                Joe: We are trying to capture what people are doing
                        There are lots of ideas around this
                        Not trying to close any doors
        Wes Hardaker: This is a cool hack
                Need to come at this from various vantage points
                Disagreemnt about whether this is even needed
                ISO's vantage point: the user is supposed to be countries that
                don't yet have a name We could be adding potential contexts for
                bad use It's their codespace from history Look what it looks
                like if we publish a document that says that we're maybe taking
                it back IETF vantage point: what is the precident if we reuse
                someone else's codepoints We would be furious if someone did
                this to us Thinks we should not do this at all Joe: History is
                not that important, but not as Wes as indicated
                        Purpose is just to document what people are doing
                        Thinks there is some benefit
        Brian: Would be useful if we could document and vaguely deprecate it if
        we have something that can replace it
                Or maybe an unsigned delegation
                Joe: There is no shortage of ideas
        Warren Kumari (no hats): If we were to document this, we should
        document all the strings
                Concerned that if we do just the 3166 codes, it will look like
                nudge-nudge-wink-wink if we just say "interesting" Joe: Agrees
                with Warren
                        If we published something, needs to be very clear about
                        what IETF means
        Wes: Looked at queries to B-root
                Number of queries for ZZ have been 4x since the draft was
                published Should document "do not do this"

Prioritisation of WG activities, Tim Wicinski
        PaulW: Doesn't like the methods being used
                There will always be drafts that are less important than the
                more important ones Wants some things removed
        Warren: If someone has said something is important, they should do a
        useful review in WG Last Call Shumon: draft-ietf-dnsop-ns-revalidation
        had delay Viktor: draft-ietf-dnsop-nsec3-guidance could be by next
        meeting PaulH: Why is alt-tld going nowhere?
                Suzanne: Needs to go look at it.
                Warren: Held it for special use domain problem statement, but
                that never finished
                        Let's move it forward (as author)
                Tim: We poke authors off-list
                        Not terribly transparent, maybe want to make it more
                        transparent Does this independently of the WG Now have
                        feedback from the poll Maybe pushing stuff down but not
                        go away
                Brian: Thinks there is interest in this, can we do a show of
                hands for this draft Suzanne: It's been parked for a while,
                will take to the list, let them review the current draft
        Benno: This session is about the process
                Some drafts might need new authors
                Need to think about alt-tld
        Tim: Maybe have between-meeting meeting about the process
                Think the boostrapping document is interesting
                Will be responsive if people raise issues
                Suzanne: People should yell at us first
                        Maybe publish a status report to the list a week before
                        the meeting
        PaulW: Send a list of items we are working on every month
                Will help people to know which to kill
                Three times a year is not good enough to do this
                Tim: We keep something like that already, internally
        Brian: At DPRIVE, had things he wants to bring that to DPRIVE
        Ben Schwartz: Wants to know where documents should go between DNSOP and
        DPRIVE Warren: Had talked about a joint interim meeting between DNSOP
        and DPRIVE and ADD