[DNSOP] a couple of DNS-related BOFs in London

Suzanne Woolf <suzworldwide@gmail.com> Mon, 27 January 2014 19:43 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C161A007C for <dnsop@ietfa.amsl.com>; Mon, 27 Jan 2014 11:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWr9rjwukhun for <dnsop@ietfa.amsl.com>; Mon, 27 Jan 2014 11:43:46 -0800 (PST)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 425931A024C for <dnsop@ietf.org>; Mon, 27 Jan 2014 11:43:46 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id x13so8524768qcv.5 for <dnsop@ietf.org>; Mon, 27 Jan 2014 11:43:43 -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=lyh/+OocAhJV7OCrU2YmbVNG+J8+BLPnQ2kht8kXX5s=; b=ffSZD7i8WAYq8bP9Juw5prHV5LFkxfJVr4lBcmmw6nEvHUBAkL989TMZsb4/oWUzAP aHez5NbwdGh2P1mA4TW1uJZShVpNmqzGmbfRW+GbadnU/ufy4Jhqc85eDzM16HYfNWWd ek/cDW7zp87ykbpds6Jst6WBHBbS4TRWfsE49EM+XbGX+zeN0I/gIctpJqyAo8lsqWPP fmx/NczFV59P6q4v/7qWy9NQe9zjgKZdYyqmwtVHdDEaRxQrmBGJE+yv+9kv/jY1j9QG jpc59xOg7b1dk8t+4letWqgXbw8xVYMRiTIZssMifbA4UoybTDacp/w59mk3sUEC1Jva 4AGg==
X-Received: by 10.224.87.193 with SMTP id x1mr18224158qal.70.1390851823875; Mon, 27 Jan 2014 11:43:43 -0800 (PST)
Received: from [10.0.0.15] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by mx.google.com with ESMTPSA id u75sm9347950qgd.23.2014.01.27.11.43.42 for <dnsop@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 11:43:43 -0800 (PST)
From: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C18FB70F-17C5-49AA-AF6A-02652BC6411D"
Message-Id: <364AE702-56ED-41D6-ACDF-3580539EF5BB@gmail.com>
Date: Mon, 27 Jan 2014 14:43:39 -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)
Subject: [DNSOP] a couple of DNS-related BOFs in London
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: Mon, 27 Jan 2014 19:43:49 -0000

Colleagues,

We're working on some other updates for London, but these BOFs may be of interest, and it certainly sounds like it would be helpful to have people knowledgeable about DNS attending. These descriptions are taken from the official list at http://trac.tools.ietf.org/bof/trac/wiki; see further details there.

best,
Suzanne

DBOUND:

Name: Domain Boundaries (DBound)

Description: Both users and applications make inferences from domain names, usually in an effort to make some determination about identity or the correct security stance to take. Such inferences, however, are usually based on heuristics, rules of thumb, and large static lists describing parts of the DNS name space.

The DNS root is expanding rapidly, and the existing mechanisms -- primarily the public suffix list (​http://publicsuffix.org/) and related systems -- are unlikely to be sustainable in the medium term. Most of the existing mechanisms are managed semi-manually, and there are good reasons to suppose that the limits of such management are either about to be exceeded, or already have been. Moreover, the existing mechanisms are made without regard to the semantics of domain name boundaries, and sometimes miss subtle but important parts of those semantics (in particular, the public suffix list has sometimes failed to take into account so-called empty non-terminals). Perhaps most importantly, the public suffix list puts the control of policy assertions about a given name outside of the control of the domain operator, and in the hands of the operator of the list.
The purpose of this BoF is to identify as completely as we can the cases in need of addressing, to identify the necessary lines of work to address each case, and to determine whether there is sufficient interest and energy to set up a working group to complete that work.


DNSE:

Name: Encryption of DNS requests for confidentiality 

Description: At the IETF meeting in Vancouver, there have been a lot of talk about pervasive monitoring, the attack it is (draft-farrell-perpass-attack and draft-barnes-pervasive-problem) and the ways to "harden the Internet", to make such mass surveillance more difficult and more costly.
Among the protocols that can reveal a lot about the users and their activity, the DNS is one of the most widely used (draft-bortzmeyer-dnsop-dns-privacy). Existing security solutions (like DNSSEC) do not provide confidentiality of the uers's traffic. There have been proposals to encrypt DNS requests, to prevent sniffing by a third-party, both inside IETF (draft-wijngaards-dnsop-confidentialdns) and outside (DNScurve).

Some of the foreseen solutions for DNS confidentiality imply a change in the protocol and therefore do no fit well in the existing dnsop working group.

So, the idea of the BoF is to start from the problem statements in draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality, and to find out if something can be recommended to improve DNS traffic confidentiality against sniffing. The recommendation could be an existing solution (such as IPsec) or a way to map DNS requests into a general-purpose security solution (such as DTLS) or the development a new standard for DNS encryption, possibly based on DNScurve/DNScrypt or draft-wijngaards-dnsop-confidentialdns. In the last case, it may require a new WG.