dnsop-wg-materials/dnsop-ietf110/dnsop-ietf110-minutes.txt

DNS Operations (DNSOP) Working Group
IETF 110
11 March 2021
Chairs: Tim Wicinski, Suzanne Woolf, Benno Overeinder
Minutes taken by Paul Hoffman
Notes here do not include material from the slides
    Mostly comments on presentations
About 125 people in the meetings


IETF 110 Hackathon DNS results
Willem Toorop
    "Soft" hackathon
    Used DNS-OARC Mattermost for communication
    Not as many participants as for f2f, but plenty of work was done
    XoT interop was good
    Suzanne: Glad that the hackathon is not being forgotten


draft-ietf-dnsop-dns-catalog-zones
Libor Peltan and Peter van Dijk
    Alexander Mayrhofer: Requirement to see the serial number of the catalog zone
        Wants a catalog of serial numbers, no matter what the form is
    Ray Bellis: Concerned abut the serial signalling
        How will they be kept up to date?
        If it is going to be mandatory, it needs to be better specified, maybe don't do that
        PetervD: PowerDNS does it synthetically, but doing it manually is harder
            Wants to keep it optional
        ISC is using this in production
    Libor: Wants more discussion of the new approach
        Could lead to a huge catalog zone is being updated frequently
    Alexander: Consider one zone that is pretty static, one is very dynamic
        Maybe list the use cases
        Target is a very narrow: inter-operator
            Can be a bit more ugly
        PetervD: That change could be easy
    Ray: Doesn't want synching should be CSYNC, is a semantic abuse
        Not sure if a new RRtype is useful, would be a metatype
    Peter Tomassen: Catalog zone size can become pretty large
        Other ways around that, such as IXFR or sharding or grouping
        Catalog might be publicly queried in the future, such as by people checking if NS has been updated


draft-ietf-dnsop-dnssec-iana-cons
Paul Hoffman
    Jim Reid: Ready for WG Last Call
        Maybe have another draft on new crypto requirements
    Dmitry Belyavskiy: Supports draft
        If this was here two years ago, he'd be done by now


draft-ietf-dnsop-avoid-fragmentation
Kazunori Fujiwara
    Paul: There is a vast range on the last slide, we can't pick a "good" value
    Benno: How can we come to consensus?
    Puneet Sood: Did 1400 on v4 and v6 for Google Public DNS
        Working well
        Maybe picking one value is impossible, instead use a range
    Jim: Impossible to converge on a single value
        Minimum value, upper value, give guideline for each
        Wants progress on this document
    PetervD: 1232 has worked well
        A resolver does not have time to probe because slows down
        Auths cannot probe MTU to clients, not implementable
    Benno: Please say on the mailing list what is implementable, what is not possible
    Suzanne: On mailing list, what can we say?
        Can we get consensus?


draft-hardaker-dnsop-nsec3-guidance
Wes Hardaker
    Roy Arends: Any change will affect millions of zones
        Has an issue SERVFAIL, would prefer to treat the zone as unsigned as current
        Happy to lower the cap
        Maybe just clarify salt or opt-out
        Wes: OK with narrowing
    Jim: On the right track
        Number 100 seems arbitrary, would prefer to have data
        Resolver operators will know more
        Wes: have data from Viktor Dukhovni, will share
    PeterT: Are there proponents for keeping salts?
        Wes: Allows larger zones to make difficult to make rainbow tables
            Only useful if you are going to rotate it
    Ulrich Wisser: How many domains will be hit if we limit to 100?
    Benno: Will take adoption to the list
    Libor: Likes 0 or 1, but most important is capping
        Maybe reduce to 10
    

draft-wisser-dnssec-automation
Ulrich Wisser
    Jonathan Reed: This is talking about the ZSK
        Guidance about pausing the ZSK rolling would be good
        Best practices on how long this should take
        Ulrich: more about the TTLs
            Maybe a day
    Ulrich: will present more at ICANN DNS Symposium


draft-reddy-dnsop-error-page
Neil Cook
    Ben Schwartz: What name is the client validating the signature against?
        Should be limited to the same domain name to limit phishing and related attacks
        Only adopted if has client side (browser) interest
        Requires total redesign of browser security model
    Tiru Reddy: Similar to captive portal standards
    Ben: Server side signing problem is also huge
        Front end processors are different between web and DNS
    Neil: Wants to get a browser vendor interested in co-authoring
    Benno: Wants more discussion on the list before call for adoption
    Neil: Maybe DNSOP is a limited audience
    Suzanne: Will try to get review in other audiences


draft-arends-dns-error-reporting
Roy Arends
    Paul: Doesn't want DPRIVE to do this on their own
    Puneet: Sounds interesting.
        This is going over unencrypted transport. What prevents spam?
        Roy: If done over an encrypted channel, error should go over channel
            Nothing can ever prevent spamming of error reports
        Some smart adversary could cause you to investigate falsely
        Roy: Can rely on on numbers of errors, have to deal with false positives
    Brett Carr: Supports
        Wants more information when failures occur
    Jim: Supports
        Need to think more about threat models
        Can't validate error codes either.
    Ben: Support, please adopt
        Maybe restrict to TCP or some other way of doing source tracing
    Matt Pounsett: Worried about getting many error reports an hour, maybe will be useless
        Who would implement?
        Maybe with TSIG?
        Roy: It is opt-in for auth server
    PeterT: Needs some tooling to aggregate and tooling
        About the zone contents itself, not errors with resolver
        Why not just tool the auth side?
        Roy: If we had such tooling, we wouldn't need it
            We don't have all such tooling
    Paul: Auth servers can change the endpoint whenever they want
    Alex: Pretty interesting
        Put a higher level of trust in protocols that are harder to spoof
    Benno: Room is positive
        Will do call for adoption

draft-arkko-dns-confidential
Jari Arkko
    Suzanne: This might be in DNSOP, or other WGs such as ADD or DPRIV
    Warren Kumari: Seems interesting
        Remote asset is very important, must show how
        Jari: Other IETF WGs are working on this
    Ben: Interested
        Lots of challenges
        Maybe a non-WG-forming BoF
        Highly speculative
        Related to PEARG
        Lots of questions of threat models and guarantees
        Privacy of things that forward?
        Jari: Maybe some interop or open source work
            Caches can confuse the timing
    Sara Dickinson: PEARG would be interested
    Daniel Kahn Gilmore: Excited about thinking about this
        Dubious about using TPMs
    Jim: Lots of policy considerations
        DNSOP might be best place because it never dies


draft-ietf-opsawg-mud-iot-dns-considerations
Michael Richardson
    Not for the WG, but wants comments from developers and operators
    Ben: RRsets are unordered and atomic
        But the answers can change often
        Cannot rely on the cache to give the same answer
        Michael: Isn't reliant on ordering, but cares about getting all of them
    PetervD: Round robin has always been statistically true
    Ben: Has hit on a real problem, but can't be solved in this draft

DANEISH BoF
Michael Richardson
    IoT security hardening using DANE
    Much about problem space
    Non-WG forming for now, charter might come later