[DNSOP] summary of WG current status

Suzanne Woolf <suzworldwide@gmail.com> Fri, 21 February 2014 17:17 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A857C1A02D0 for <dnsop@ietfa.amsl.com>; Fri, 21 Feb 2014 09:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3AvN67SDFuvg for <dnsop@ietfa.amsl.com>; Fri, 21 Feb 2014 09:17:52 -0800 (PST)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D118F1A01BF for <dnsop@ietf.org>; Fri, 21 Feb 2014 09:17:51 -0800 (PST)
Received: by mail-qc0-f170.google.com with SMTP id c9so6117291qcz.15 for <dnsop@ietf.org>; Fri, 21 Feb 2014 09:17:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=Q+5ORYs8ajnIrFxvUkZZTeSjnvU/UGCbnH4WA/awh6o=; b=PeLyAlz4Hv+RF/EXYhoSwSG6Dw5xdBL36rFjoi2QawDp+aFt4z0LRk3x9FGrjmwMIK waKqUOlBlE2bYVrWfFGc2Pb8BgCB0/NS1FW2irvrluJFtWXGPcMxFRU6EyaNyLAcHoCl UGYK9yl2ODtXC+0NDDxaHCJXbO++1YpV5YFl00FM7NHz+X0wRe6Oq6UtUS3tqvnRCSTB aWB/FK8VnuKLasmTURWWWPf9fwc40K+JyVKsKgwP3atT+uHmPSkbMnpl3F2qajC/cNAx t9U81MQelKqQvWSCACCmtU2z+WhGmNfxf1L5S2Eco48ROKzxM1ynA7LEfrrHtI834NN/ d/1w==
X-Received: by with SMTP id z91mr11129041qgd.32.1393003067738; Fri, 21 Feb 2014 09:17:47 -0800 (PST)
Received: from [] (c-24-63-89-87.hsd1.ma.comcast.net. []) by mx.google.com with ESMTPSA id z18sm23459804qab.5.2014. for <dnsop@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 09:17:46 -0800 (PST)
From: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_75454918-A9F3-4FAB-A010-E403C1C7D1CD"
Message-Id: <8AA00477-DFDA-4A7A-9A30-76AFB88BE4CA@gmail.com>
Date: Fri, 21 Feb 2014 12:17:50 -0500
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/e154LBSsSfXNgxb1O1zZAcjQeuM
Subject: [DNSOP] summary of WG current status
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 17:17:55 -0000

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.

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.

5. to reserved list
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

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.

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