DNSOP Minutes Monday July 20, 1525 Minutes taken by Paul Hoffman Things from the slides are not copied here, see the slides themselves Agenda: https://www.ietf.org/proceedings/93/agenda/agenda-93-dnsop Slides: https://datatracker.ietf.org/meeting/93/materials.html List of old documents was covered Paul Hoffman talked a bit about WG Last Call participation Why these reviews are important DNS Transport over TCP -- draft-ietf-dnsop-5966bis Sara Dickinson Lots of recent discussion on the mailing list Hard to mandate what servers and clients must do Bernie Volz Does the idle time apply to just the connection opening? Round trip time comes into play Wants a different value for the first request, maybe clarify more Geoff Huston BGP has persistent TCP connections Makes them more vulnerable to reset attack Should reference the risk of reset connections RFC 4953 Ray Bellis: where is the problem Geoff: extended idle time gives attacker more opportuniy Erik Nygren: Anycast makes you want to be able to really do a reset edns-tcp-keepalive EDNS0 Option -- draft-ietf-dnsop-edns-tcp-keepalive Sara Dickinson Question of motivation for the document Trying to clarify the motivation Does this document meet the new needs of the WG? Some of the authors were the ones criticl earlier Andrew: had an early idea where the client said "I can do this" and the server could determine if the clients really did it Sara: Similar usage now, but with the server saying "this is what we expect you do" Some clients could say "let's keep this connection up longer" Ted Lemon: Do we have data to suggest which context for long-lived connections Sara: DNSSEC validating resolvers, Joe Abley: Large number of same questions Early approach: not clear how to implement Likes new document much better John Dickinson: Server can't send EDNS by itself Don't want the server to be reliant on the client to say something David Lawrence: Attack: spoofing well-known resolvers Linus (?): DNSSEC over Tor could benefit from this Would like feedback on the new approach People volunteered to review: Duane Wessels David Laurence Aggressive use of NSEC/NSEC3 -- draft-fujiwara-dnsop-nsec-aggressiveuse Kazunori Fujiwara Proposed a new flag to indicate that it supports aggressive negative caching Warren Kumari: There is already some implementations for the root Ralf Weber: This makes some big changes to the operations Ignoring the CD would get wrong data Kaz: If you have enough data in the cache, you know enough when to not do this Rob Austein: 4035 was told not to touch it because it changes caching Is disturbed by the NS bit We are overloading CD bit now Breaks end-to-end DNSSEC Peter Koch: We change ages-old portions of the protocol without saying why We get confirmation bias, but we don't see confirmation bias What prevents the resolver from setting AN always? Paul Wouters: The AN bit disables online signing and allows zone walking Olafur Gudmusson: Not talking about opening it all the way up Strongly supports John Levine: Would be RDNS and DNS black lists, particularly for IPv6 Mark Andrew: CD=1 doesn't work through a recursive server Mathematically provable Fix this first Avoid getting the wrong NSEC DNSSEC Trust Anchor Publication, Abley -- draft-jabley-dnssec-trust-anchor Joe Abley Mike St. Johns: Is 5011 off the table Joe: 5011 will be followed by some validators, but we know some don't do it or do it badly John Dickinson: Problem with 5011 is lack of signalling Will probably do a draft to tell people to not differentiate between 5011ish keys Also: EDNS option to say what trust anchos they know of Wes Hardaker: Wants just one way to do things Joe: There can also be a bootstrapping problem This is orthogonal to 5011 Wes: Do we need 5011 even if we do this Mike: All this does is move the trust problem back one level Joe: There is already a way for software to update software John: We should give unmanaged servers some pain Joe: Then some manufacturers won't do DNSSEC at all We currently have nothing to tune George Michaelson: Client signally would be great Ed Lewis: Don't put all eggs in one basket Simplified Updates of DNS Security Trust Anchors -- draft-wkumari-dnsop-trust-management Warren Kumari Main idea: know who is going to break Olafur: TALINK did this If you are going to do this, make it is possible for stubs to ask recursives what they are using Roy Arends: This will leak who has the old keys and is going to fail, should be flagged Maybe a generic way for any client to say what it supports Stephane: Worried that this will cause a delay in rolling the root key How will the administrator will guess what percentage of resolvers don't do this Warren: Any visibility is better than none John Dickinson: But this has to be signed by the KSK only On No, Not More NameSpace Discussions, P2P Drafts draft-grothoff-iesg-special-use-p2p-i2p draft-grothoff-iesg-special-use-p2p-gns draft-grothoff-iesg-special-use-p2p-exit draft-grothoff-iesg-special-use-p2p-bit Christian Grothoff Suz: We are starting a design team Lists the history, plus now there is a consideration of .tor George Michaelson: Some of these names don't use DNS semantics Christian: Only share the namespace Andrew Sullivan: Some of these are attacks on the way that the DNS works ...and thus a bad idea If you don't use the domain name space rules, you don't get a name Don't ask the IETF to help you compete with the DNS business model Distinction of Namespace Alain Durand and Peter Koch George Michaelson: Every name will appear in the DNS Poses an impossible goal Stuart Cheshire: The namespace is not the DNS /etc/hosts, nsswitch Already has multiple resolution mechanisms We are stewards of that shared namespace Alain: The global namespace has to be unique Joe Abley: We are reinventing ICANN in the IETF, but with a negative names Peter: Process for not being put in the root Stephane Bortzmeyer: Doesn't think it is a good idea to update 6761 The draft-grothoff drafts must move forwards because 6761 exists We must be honest about our rules Wes Hardaker: The separation should be done above the current namespace Mark Andrews: .home is really the DNS, but is ambiguous Patrik Fälström: There is no process for adding things to the root of the DNS