Minutes for DNSOP at IETF-93
minutes-93-dnsop-1

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