All Big thanks to Paul Hoffman for pulling all these together.
Where are they? All the usual places: https://notes.ietf.org/notes-ietf-112-dnsop https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-ietf112/dnsop-ietf112-minutes.txt https://datatracker.ietf.org/meeting/112/materials/minutes-112-dnsop-00 Plus I attached them so nobody has to think hard after this week. Thanks all. An email with actions will go out next week Benno/Suzanne/Tim
DNSOP WG at IETF 112 November 11 and 12, 2021 On Meetecho, not in Madrid Agenda is at https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop Minutes here only reflect the mic line, not text on the slides Chairs discussion Guidance for NSEC3 parameter settings, Wes Hardaker draft-ietf-dnsop-nsec3-guidance Ted Lemon: Questions choice of insecure for validating stub resolver Stub resolver might want to treat >100 as an attack Wes: Gut reaction is that splitting types will lead to chaos Precedent is to act like NSEC3 works today Viktor Dukhovni: When we treat high counts as insecure, every answer under that must be treated as insecure Gap between insecure and SERVFAIL: SERVFAIL allows the zone to be treated as secure Jim Reid: Agrees with Ted, would prefer to respond with SERVFAIL instead of insecure at 0 or 1 Ralf Weber: Middleground can cause problems, just have one signal Wants a hard cut Wes: Maybe have draft allow sliding toward goal Petr Špaček: Be strict for zone owners, but allow sliding for validators Just describe for validators why there are thresholds, but don't give values Describe the properties Benno Overeinder (as implementer): Agrees with Petr Thanks Viktor for doing the measurements DNSSEC automation, Ulrich Wisser draft-wisser-dnssec-automation Shumon Huque: Working on the draft has helped get providers to implement the key operations part Will get more progress if this is a WG document Paul Hoffman: Does this need to be in DNSOP, or maybe a different WG that is more operator-specific Peter Thomassen: If the receiving operator uses a different algorithm, there could be protocol implications Ralf: Thinks this belongs in DNSOP Viktor: Implementers of nameservers might need to make changes to software, so leave it here Ulrich: Requires complicated state machine in the nameserver to make this work Will have implementation in coming months, testing before IETF 113 Survey of Domain Verification Techniques using DNS, Shivan Kaul draft-sahib-domain-verification-techniques Paul Wouters: This is very important, already a huge problem Shumon: Current use is quite ad hoc, big security gap Joey Salazar: Other than a security analysis, what are the next steps? What has changed since last meeting to support adoption more? Shivan: Collecting issues Will add section comparing TXT vs. CNAME Benno: Discussed how this can fit in with other documents in the queue Tim Wicinski: Don't stop working on this, it's important Shumon: Will keep plugging, but want more collaborators Brett Carr: Supports; suggests that the title be changed to not just be about survey Shivan: Will be more about guidance instead of prescriptive PeterT: Wonders who the target for the draft is Wants to be sure the major users are involved in preparing the draft Shumon: Will do outreach to the communities that are already doing this Ask what would persuade them to adopt this PaulW and Brett volunteered to help Structured Data for DNS Access Denied Error Page, Dan Wing draft-wing-dnsop-structured-dns-error-page Ben Schwartz: Very cautious about anything that lets the DNS operator to jump into a web conversation There are no safe use case in the web context Would like a shift to technical use cases and debugging Could also be used for other DNS failures; an addendum for extended error code Should not be shown to the user to lie or scare them Jonathan Reed: Sees a use case for debugging and enterprises Wants an indicator with an NXDOMAIN Can be in the middle ground between blocking and full access Could be a signal that "it's not just you" Andrew Campling: Bad censors work just fine, this helps good censors Gives visibility to the good cases Current UI is crap, this gives a better end-user experience in enterprises Eric Orth: It should be scary Agrees with Ben Usable for debugging, like EDE, but wants more info on PaulH: Is scared by the idea that this is for enterprise only (from earlier speakers) Dan: Saying what is and isn't enterprise is impossible Is meant for the whole Internet Brian Dickson: Thinking about RPZ changing response codes Could add provenience in these responses based on trust of the source Dan: Didn't go that way because of requirements for DNSSEC Various drafts, Brian Dickson draft-dickson-dnsop-ds-hack, draft-dickson-dnsop-glueless, draft-dickson-dprive-adot-auth, draft-dickson-dprive-dnst Ben: Thinking along the same lines, good that we have lots of interest We are not ready to jump in on any of these SVCB-DNS is adopted in ADD WG, similar to DST, would prefer not to have multiple methods Brian: was using none of the value proposition, did DST as a shortcut Agrees we should not have two ways, wants more expedient Glueless delegations have a lot of security properties Assumes that this set of queries are non-sensitive Wants more discussion on this Viktor: What does NSV bring to the table? Wants more discussion about value in cases where there is already encryption Brian: Doesn't assume that data encryption gives data integrity Why new TLSA type? Brian: Motivation to remove the prefixes is for better signaling Daniel Kahn Gillmor: Have you attempted to deploy the NSV algorithm to active zones? Brian: Tried a few, but couldn't get past the UI Easier to get deployment if they have an early allocation Doesn't expect pushback from registry operators Viktor: Some registries reject new types [[ Beginning of second meeting ]] DNS Catalog Zones, Willem Toorop draft-ietf-dnsop-dns-catalog-zones Wes: Some names will leak; what are you thinking of naming for the left side? Would like examples under .arpa, don't use a real TLD Willem: Agrees PeterT: How about suggesting only using only names they own? Willem: Or a reserved TLD PaulW: Was initially skeptical, is now really happy with it Likes the multi-vendor part Kudos, keep going Viktor: Questions the security of the transport Willem: It's in the draft Could these zones be signed? Is this crazy? Willem: Interesting to consider Benno: Getting close to WG Last Call Already implemented, getting feedback from users Willem: Interop testing still going on IETF Hackathon DNS Results, Willem Toorop Tom Carpay presented on EDER results (see slides) Peter van Dijk: Asked if there was a bug in the spec or in the testing Tom: In the testing Ben: Why are you sending an unsolicited extension Willem: Was discussed at last iterim Wanting to determine if this is OK Questions whether 0.1% is too high Willem: This might be due to the normal DNS error rate Will like to see more testing Guidance for NSEC3 parameter settings (nsec3.2), Wes Hardaker draft-ietf-dnsop-nsec3-guidance (new set of slides) PaulW: Don't normally expiry dates Don't think this should be in the document Should appear in the normally-updated document Wes: This is history, not future "As of this publication" Petr: Maybe make a history appendix This is not setting any expire date, doesn't see the objection Viktor: Maybe just recommend 100 as the upper bound for the upper bound Wordsmithing Peter Koch: Are we talking about operators or vendors? Wes: Will clarify difference Petr: As a vendor, needs reasonable guidance for defaults Suzanne: Much more on the mailing list Send text Viktor: PeterK if he has any problems reducing to 0 PeterK: Has a concern of the approach of driving this through by a standard Slippery slope that this is a compliance game Wes: It is a security issue Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator, Peter Thomassen draft-thomassen-dnsop-dnssec-bootstrapping Glad people chimed in on the hashing discussion Viktor: Let's adopt, without hashing PaulW: Likes the majority of the work Benno: Are adopting new work, but in a controlled way Are on the short list Suzanne: Will likely have interims between IETF meetings
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
