minutes

dnsop-ietf112/dnsop-ietf112-minutes.txt

@@ -0,0 +1,162 @@
+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