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. 
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to