Subject: [DNSOP] summary of WG current status

From: Suzanne Woolf <[email-masked]>
Date: Fri, 21 Feb 2014 12:17:50 -0500

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/

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 **

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 21 Feb 2014 21:06:58 +0100

WOW! This could be a week of meetings...

I guess it is not time to fold yet... :-P

   Patrik

On 2014-02-21 18:17, Suzanne Woolf 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
> 
> 
> 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.
> 
> 2. PRIMING draft
> (http://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/)
>     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.
> 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
>     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
> drafthttp://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/)
> 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. 
>     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/andhttp://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.
> 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.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 21 Feb 2014 16:06:15 -0500

On Fri, Feb 21, 2014 at 12:17 PM, Suzanne Woolf <[email-masked]> 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
>
>
>     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.
>
>     We've also got a new rev of this draft so we can resolve the open
> questions and get this published also.
>
>     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.
>
> 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.

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

> 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:
> discussion of privacy and confidentiality with regards to the protocol and
> operations of DNS:
>
>         Stephane's solutions draft
> http://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-privacy-sol/)
> 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.
> 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.
> 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.
>

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 21 Feb 2014 16:41:01 -0500

Warren,

You're right-- our apologies for a misunderstanding combined with a bad edit in the summary as sent.

Both drafts are on the agenda for London, so you (all the authors) can do an update if you feel it's necessary, and we'll move them ahead for final review/WGLC.

Thanks for your attention and helping us get it right :)

best,
Your Chairs

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Feb 2014 15:12:27 +1100

In message <[email-masked]>, Suzanne Woolf writ
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/

add to that
 http://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]