Minutes IETF109: dnsop
minutes-109-dnsop-01

DNSOP WG
IETF 109, virtual (would have been Bangkok)
Chairs: Tim Wicinski, Suzanne Woolf, Benno Overeinder
Minutes taken by Paul Hoffman
Text from slides not shown here; see the slides for much more info

Session 1: 17 November 2020, 1200-1400 +7, 0500-0700 UTC

Administrivia
    Review of documents moved forward since last meeting

Delegation Revalidation by DNS Resolvers, Shumon Huque
    https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
    Ralf Weber: Feels strongly that we should not do this work
        Wandering way too far into implementation territory
        There are other ways to do resolution
        This will be abused
        Trying to implement something that helps one or two use cases
        Will make resolvers more abusable.
        Shumon: consensus went the other way
    Brian Dickson: Does this take into consideration extended errors?
        GoDaddy uses error code 20 (explains "refused")
        Shumon: thinks this is reasonable

Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for
DNSSEC, Dmitry Belyavskiy
    https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/
    Peter van Dijk: Would really like test vectors in the draft
        Dmitry: they are there
    Jim Reid: Is they crypto code in many libraries?
        Dmitry: Yes in OpenSSL, Linux kernel
    PaulH: Wants to wait for WG Last Call until we know if it will needs to be
    on standards track

Top-level Domains for Private Internets, Roy Arends
    https://datatracker.ietf.org/doc/draft-ietf-dnsop-private-use-tld/
    Ted Hardie: Likes the idea for splitting the drafts
        What does "locally used" mean
        Thinks the second document shoudl be by ISO talking to ICANN, not from
        IETF This would make it essentially impossible for ISO to change the
        use Does not feel it is right for IETF to do that to ISO Joe Abley:
        Different cans for different worms
            Try to limit the scope to just the things that IETF can think about
            Observation that we have used thise before; just document that
            Noting that code points have been used in the past
            Historic 3166 policy
        Roy: ISO has already said that the names are reserved locally
            ICANN has adopted ISO's policy
            Look as a Venn diagram
            Needs all three to say that they can be locally used
    Brian: ISO says these names are not used and will never be used
        This is about IETF saying that we will not use these per se
        Roy: Let's make it explicit for everyone
    Warren Kurmari: Policy implications
        ICANN CEO sent statement to IETF
        Response from IETF and IAB
        Want to engage experts between IETF and ICANN
    Ted: Two pieces that need to be more careful
        Serious distinction between intent and the conclusion and that they
        should be used in the DNS for this purpose These are being squatted on,
        and we see this happening We think we know what they can be used for,
        so we can get ISO, IETF, ICANN to be in agreement Don't just draw the
        conclusion, make it cleaner
    Eberhard Lisse: ccNSO has thought about what happens if a country stops
    existing
        Has been looking at ISO naming carefully
        ISO has been predictable in saying that the code points are not part of
        the standard Extremely unlikely that any will be changed Makes sense to
        split it into two drafts
    Stuart Cheshire: Whenever you say something is reserved, people think it is
    reserved for them
        Need to say it is reserved for
        Conflicting local uses
        Tempting to say "do what you like", but this is abdicating its
        responsibility Need to say what purpose it is reserved for
    Jim: Documenting everyone else is using these for is inappropriate or
    relevant
        Useful for background
        Roy: Move to an appendix of examples, non-normative, anecdotal
    Warren: Agreed with Ted and Stuart's concerns
        Doesn't like "extremely unlikely"
        Uncoordinated use makes it hard to undo future problems
        Wants to hear from ISO that they will never reassigns

Fragmentation Avoidance in DNS, Kazunori Fujiwara
    https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/
    Mark Andrews: This document doesn't talk about recovery when you are using
    TSIG
        TSIG reply can be fragmented as much as you want, it won't be
        misinterpreted This document should take into consideration TSIG-signed
        requests TSIG prevents reassembly attacks This draft should have
        different replies for a TSIG message than non-TSIG message Kazunori:
        Likes the well-known TSIG draft Mark: Differnet problem space
            Will try to send text to the list
    Ralf: TSIG is only a small part of DNS traffic
        Fragmentation within IPv6 is just not working
        Maybe only TSIG over v4
        Mark: v6 fragements can be delivered reliably
            v6 is in early deployment
        Difference between fragementation and header extensions
    Tim: Needs to be on the list
    Peter: All DNS vendors have come together to agree on a default size, that
    this document disagrees with
        This document is devisive; that text should be removed

Revised IANA Considerations for DNSSEC, Paul Hoffman
    https://datatracker.ietf.org/doc/draft-hoffman-dnssec-iana-cons/
    Tim: Some implementors had issues with how do we give guidance to them
    about what to implement
        Paul: This will tie right into this document
            Post-quantum will be much more painful
    Dmitry: Fond of the idea to lessen the requirements
        Not sure if changing the process for draft-ietf-dnsop-rfc5933-bis is
        the best possible solution
    Mark: Go with RFC required
        Specifications are not stable, they disappear
    Jim: Prefernce is specification required
        Wants something light-weight
        Requiring RFC seems overkill
        Paul: Some protocols have done just fine with "specification required",
        but some specs have disappeared (such as in S/MIME) Follow what other
        WGs are doing
    Tim: If a code point can be assigned sooner rather than later while the WG
    works on this document, that may keep things moving along for him as well
        Paul: Then the WG needs to discuss whether the WG wants to standarize a
        signature algorithm that is less secure than EdDSA
    Lars-Johan Liman: Differentiates between records
        Structure-carrying records require special processing in the server (NS
        records, DNSSEC-related, ...) Data records (just carry data) Wants a
        distinction betweeen the two, and wants RFC required for
        structure-carrying
    Dmitry: mentioned that the algorithm's parameters are as good as EdDSA
        Paul: agrees and apologizes
    Brian: Specifications disappear
        If something gets approved, maybe create a backup copy of the specs
        periodically as an informational RFC
    Warren: We used to pull IDs from the archives, but they are now kept around
    forever

Recursive Resolvers IP Ranges location distribution and discovery, Manu Bretelle
    https://datatracker.ietf.org/doc/draft-bretelle-dnsop-recursive-iprange-location/
    Ben Schwartz: Not a good use of HTTPS record
        Would help with service bindings in URI or TXT
        Distributing the list of IP prefix seems OK, but confused about geocodes
        Why is the location of the resolver of any interest
        Manu: Resolvers are using geo now, but is not the most granular
        Ben: Can understand using geocoding for country-specific service
        requirement
            Is this about latency optimization? If so, use user location
        Manu: few people can build latency-measuring systems
    Liman: Don't use TXT; not the kitchen sink
        Conflating the resolver side with the authoritative side; should be
        disjunct A better place to put this information is in the query from
        the rsolver Mark: Idea is to create collections of resolvers into a
        country
    Joe: ECS exists because the state of the art was using the address of the
    resolver
        It's a real problem
        Real world example: resolver cluster had to have 200 exist addresses
        just to work
    Mark: Look at APL records
    Alex Mayrhofer: URI record with a "geo:" URI, doesn't use TXT

DNS Access Denied Error page, Tirumaleswar Reddy
    https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
    Ben: Why is a web page better than extended error code
        Tiru: Extended errors allows cleartext responses, this is protected web
        Ben: Start deploying EDE first before considering this
            Why is there a signature tied to the TLS signature?
        Tiru: To hadle upstream services from forwarders
    Joe: EDNS options are hop-by-hop
        How would they be passed back?
        Other than DoT/DoH, there are usually intermediaries
        Not a solution for the general case
        Tiru: Thinks it is clear
    Wes Hardaker: Didn't come to consensus on EDE that the free text is for
    logging
        This draft significantly differs from that
        There be dragons

===================================================================================================

Session 2: 20 November 2020, 1430-1530 +7, 0730-0830 UTC

IETF Hackathon DNS results, Willem Toorop
    Used DNS-OARC chat service
    14 signed up
    May do it again for IETF 110

DNS Error Reporting, Roy Arends
    https://datatracker.ietf.org/doc/draft-arends-dns-error-reporting/
    Jonathan Reed: Is there any data on cases where the authoritative is up
    enough to report
        Roy: DNSSEC is big one
            Even lame delegations can be reported this way
            In almost all cases the auth has something to report
            Lame delegation is a harder case; need to figure out more
    Jim: Likes the draft
        What is the role of the reporting agent?
        Are they gathering telemetry data?
        Wants more text about the role
    Ralf: Is there any way to prevent people about lying about the reporting
    server
        Roy: No. Anyone can send anything anywhere.
        Could be abused, keep it separate from your normal name servers
            Roy: It's already in the draft
        Will send thoughts about abuse scenarios
    Bernie Hoeneisen: Does this have anything to do with network blocking?
        Roy: No, it's orthogonal, because you would have gotten a response back.

DNS over HTTPS (DoH) Considerations for Operator Networks, Jim Reid
    https://datatracker.ietf.org/doc/draft-fhllr-dnsop-dohoperator/
    Ben: Would not want to use it as a starting point
        Has bad information, too much regulatory stuff
    Mark McFadden: Good to use here
        Documenting it needs to be done somewhere
    Stephen Farrell: Doesn't understand how this could finish before ADD does
    its work Ted: Landscape is changing fairly fast
        Not the time to write down the best practices
        Maybe ask questions now, but this is not ready for publication
    Andrew Campling: Agrees with MarkM
        Serves a useful purpose
        Doesn't see linkage to ADD
        Important to get operator experience
        Good starting point
    Paul: Thinks it should be done, but not in DNSOP
    Tim: Understands the operational points of view
        Policy stuff will be a minefield, makes him nervous
        If DNSOP doesn't take it on, it will still be vetted here
        Jim: Policy stuff makes him nervous too
            Say that "these are what the policy issues might be; there might be
            dragons" Not asking the IETF to work on them
    Ben: This is not our place, and thus not useful just to say "they exist"
        By documenting anything in an RFC, you imply that certain policy
        choices are correct or even exist
    Andrew: It is reasonable to note that policy issues exist, and OK to
    highlight them Suzanne: Need to decide if this is not in scope for DNSOP,
    relationship to ISE
        Would the community benefit from DNSOP adopting this document
        Can continue discussion on the mailing list, or send messages to the
        authors

Delegation Information (Referrals) Signer for DNSSEC, Kazunori Fujiwara
    https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/
    Peter: Something like this might be the thing that works for DPRIVE
    Ben: Very interesting
        Overlaps with lots of DPRIVE
        Maybe move to DPRIVE
    Jim: Interesting draft, not sure if it is really needed
        Not sure if the signed meta-data is needed
        Is this part of DS set, or meant to replace it
        Add complexity, could make it worse
        Needs cost/benefit analysis
    Peter Koch:
    Olaf Kolkman: Was very careful not to muck with what we didn't know at the
    time
        Afraid to over-step, make the most minimal changes to the DNS