Re: [DNSOP] summary of WG current status

[Warren Kumari <[e-mail]>]

On Fri, Feb 21, 2014 at 12:17 PM, Suzanne Woolf <[e-mail]> wrote:
> Dear Colleagues,
>
> As we look towards the meeting in London, we have several items in progress,
> which we've organized here from the most specific and administratively
> simple tasks to the broadest discussion topics.
>
> Not everything called out here is on the London agenda, but we've tried to
> round up everything that's in progress as work for the WG, formally or (in a
> few cases) informally. We expect to send this out periodically, not least so
> people have a chance to call us on it if we drop stuff.
>
> thanks,
> Your Chairs
>
>
> From our existing charter:
>
> 1. RESPSIZE draft
> (http://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/)
>     This item has been in our charter for a very long time, and was at one
> time considered almost ready for publication but stalled there. There's been
> recent interest in dusting it off and getting it shipped, and with the help
> of the previous authors and a new volunteer, a new version has been
> published. It's been suggested  we might want to add some more material on
> DNSSEC and EDNS0, since the previous version only dealt extensively with the
> impact on referral size of adding AAAA records and the bulk of the document
> was written before the root was signed or ICANN's registry contracts were
> written to require DNSSEC for new gTLDs.
>
> Agenda in London: flag open items, get reviewers, get a timeline for
> finishing
>
>
> 2. PRIMING draft
> (http://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/)
>     We've also got a new rev of this draft so we can resolve the open
> questions and get this published also.
>
> Agenda in London: flag open items, get reviewers, get a timeline for
> finishing
>
> 3. AS112 operations:
>     http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ (WG item)
>     http://datatracker.ietf.org/doc/draft-jabley-dnsop-rfc6304bis/ (new)
>
>     Some additional "bits and pieces" re: AS112 operations. We need
> reviewers to move forward with the DNAME one, and for 6304bis if we want to
> adopt it.
>
>     Agenda in London: determine momentum for getting these reviewed,
> revised, and published. If not they will be dropped.
>
> 4. CDS and related: what are we doing about the topic of DNSSEC in-band key
> maintenance? This has previously been somewhat contentious and seems to have
> stalled without resolution. We now have current versions of two drafts and
> would like to make progress on resolving differences.
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/

We don't think that there are differences -- they are *complementary*,
not *competing*.
They solve related, but different problems.

From: http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
"  The solution described in this document only allows transferring
   information about DNSSEC keys (DS and DNSKEY) from the child to the
   parental agent.  It lists exactly what the parent should publish, and
   allows for publication of stand-by keys.  A different protocol,
   [I-D.csync], can be used to maintain other important delegation
   information, such as NS and glue.  These two protocols have been kept
   as separate solutions because the problems are fundamentally
   different, and a combined solution is overly complex."
and:
   "Special thanks to Wes Hardaker for contributing significant text and
   creating the complementary (CSYNC) solution, and to Paul Hoffman and
   Mukund Sivaraman for text and review."


And from: http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
   "This specification does not address how to perform bootstrapping
   operations to get the required initial DNSSEC-secured operating
   environment in place.  Additionally, this specification was not
   designed to synchronize DNSSEC security records, such as DS pointers.
   For such a solution, please see the complimentary solution
   [I-D.kumari-ogud-dnsop-cds] for maintaining security delegation
   information."
and:
   "A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson,
   who's work on the CDS record type helped inspire the work in this
   document, as well as the definition for "Parental Agent" and "DNS
   Publisher" definitions. "

There is no monkey knife fight here -- we are all one big happy family.
The CDS authors believe we have integrated all the suggestions and
addressed the questions and would like to go to WGLC.

W



>
> 5. 100.64.0.0/10 to reserved list
> http://datatracker.ietf.org/doc/draft-andrews-dnsop-rfc6598-rfc6303/
> Stalled in WGLC on an administrative issue of overlapping IANA registries.
> Chairs will review discussion and propose a way forward soon; no WG action
> required
>
>
> NEW TOPICS:
> Passive DNS data format:
> http://datatracker.ietf.org/doc/draft-dulaunoy-kaplan-passive-dns-cof/:
> needs review, call for adoption
> Authority server placement: no i-d yet; agenda time requested, needs review
>
> FOR DISCUSSION, including possible charter revision:
>
> 1. Privacy drafts
>     There are *at least* four i-ds and a BOF in London specifically for
> discussion of privacy and confidentiality with regards to the protocol and
> operations of DNS:
>
>         Stephane Bortzmeyer's problem statement draft
> (http://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-dns-privacy/) is
> reasonably on-charter for us.
>         Stephane's solutions draft
> http://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-privacy-sol/)
>         Peter Koch's draft on information leakage in the DNS
> (http://datatracker.ietf.org/doc/draft-koch-perpass-dns-confidentiality/)
>         Wouter Wijngaards' draft on opportunistic encryption in the DNS
> (http://datatracker.ietf.org/doc/draft-wijngaards-dnsop-confidentialdns/)
> (plus a few other documents)
>
> We need to decide what we think a useful contribution on this broad topic
> would be for DNSOP. Stephane's problem statement draft seems in-scope and
> we'd like to call for adoption. Protocol changes as described in two of the
> drafts probably need a new WG. In between, this topic provides an
> opportunity for us to consider reasonable updates to our charter given
> evident demand from the community to examine DNS in light of current privacy
> concerns.
> ** This is a major item for the agenda in London; please come prepared to
> discuss **
>
> 2. Special names
>     There are two current drafts requesting additions to the Special Use
> Names registry as per RFC 6761,
> http://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/
> and http://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/.
> The process described in RFC 6761 calls for "IESG action," and the IESG has
> asked for DNSOP input, including that we consider adopting these drafts as
> WG items. We have already had some discussion on these drafts, and the
> current process, based on RFC 6761, makes whether to add these names to the
> registry the IESG's decision. We will continue to discuss these drafts on
> the mailing list and provide our advice/observations to the IESG.
>
>     There is some interest separately in the broader architectural concerns
> around "what should we do with requests/needs for namespaces that look like
> DNS names, but aren't?" As it looks like these uses of DNS-like namespaces
> by non-DNS protocols will continue to evolve, and the RFC 6761 process
> already seems problematic, we need to consider whether there's work to be
> done in fine-tuning the IETF's response to these requests from protocol
> developers who are trying to do the right thing, don't want to simply
> appropriate namespaces a priori, but are not actually trying to do DNS
> protocol or operations and simply want to avoid incompatibility.
>     http://datatracker.ietf.org/doc/draft-wkumari-dnsop-alt-tld/
>     https://datatracker.ietf.org/doc/draft-ogud-appsawg-multiple-namespaces/
>
>
> DNSEXT discussions
> - tcp keep-alives
> - tcp query-chaining
> - DNS cookies
> - TLS for DNS
>
> DNS Cookies & TLS for DNS
>
> Donald Eastlake has generated a new version of the DNS Cookies draft, which
> incorporated many comments.  Several other contributors have also written a
> new draft on the use of TLS for DNS over TCP. While these are out of scope,
> we feel with the privacy and confidentiality work swirling,  there seems to
> be room to at least have the discussion.
>
>
> New charter
>
> DNSOP has been around for awhile, without a recent charter revision even as
> topics including privacy, root zone expansion, and changes in the
> operational environment have become increasingly important. Our Esteemed AD
> has been very open with us pulling things in for discussion, especially if
> there are operational impacts from such things.  We're working on a new
> charter that would include a couple of specific items the WG has already
> adopted or considered, and a shift in scope to allow DNSOP to provide a home
> for problem statements related to DNS in much the way v6ops does for the
> IPv6-related groups and issues. Your suggestions are appreciated.
>
> ** This is a major item for the agenda in London; please come prepared to
> discuss **
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>