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