Categories
Deploy360 Domain Name System (DNS) IETF

DNS Security & Privacy discussed at e-AGE18

The Internet Society continued its engagement with Middle East networking community by participating in the e-AGE18 Conference, where we took the opportunity to promote the importance of DNS Security and Privacy. The conference was held on 2-3 December 2018 at the Marriott Hotel in Amman, Jordan and was organised by the Arab States Research and Education Network (ASREN) and co-sponsored by the Internet Society.

Kevin Meynell from the Internet Society’s Middle East Bureau, highlighted the importance of implementing DNSSEC which allows DNS resolvers to authenticate the origin of data in the DNS through a verifiable chain-of-trust. This reduces the possibility of spoofing where incorrect or corrupt data is introduced into a resolver, or a man-in-the-middle attack whereby DNS queries are re-directed to a name server returning forged responses.

Unfortunately, only the Saudi Arabia ccTLD (.sa) has operationally deployed DNSSEC in the Middle East region at the present time, although Iran (.ir) and Iraq (.iq) have deployed it on an experimental basis. On the positive side, around 18% of DNS queries originated from Middle East countries are being validated compared to 12% globally, with Yemen (45.1%), Saudi Arabia (32.1%), Iraq (30.6%), Bahrain (23.2%) and Palestine (22.5%) leading the way. This is possibly because there is a greater prevalence of the use of third-party DNS resolvers (e.g. Cloudflare, Google, Quad9 in the region.

Of course, whilst DNSSEC ensures that DNS records have not been modified without the owner’s consent, it does not keep the queries themselves confidential. DNS queries reveal what site a host is communicating with, and as they are (by default) sent in clear text, they can easily be eavesdropped.

The IETF DNS Private Exchange (DPRIVE) Working Group has therefore recently developed mechanisms to encrypt queries and responses to/from resolvers and therefore provide some confidentiality of DNS transactions. These include DNS-over-TLS (DoT), DNS-over-DTLS (DoD) and DNS-over-HTTPS (DoH), and with the exception of DoD, there are already several public DNS resolvers (Cloudflare, Quad9 & CleanBrowsing) and a few clients (Stubby 1.3+, Unbound 1.6.7+, Knot 2.0+, Mozilla Firefox 62+ and Android 9 Pie) that support these mechanisms.

It should be pointed out that clients and resolvers need to be upgraded to support DoT and DoH, and all these mechanisms currently only encrypt DNS communications between client (stub-resolver) and recursive resolver, not between recursive resolver and authoritative DNS servers. Support for the latter would require all authoritative DNS servers to be upgraded to support DoT and DoH, and there are concerns about the increased computing requirements that would required on the more heavily name servers to initiate the encrypted connections.

In addition, providers of the recursive resolver are in the position to monitor and log queries and responses, so need to be trusted. Nevertheless, these are important developments towards improving the security and confidentiality of the DNS.

Last but certainly not least, attention was drawn to DNS Flag Day which is important to be aware of. DNSSEC and other extended features of the DNS require EDNS0 (Extension Mechanisms for DNS – RFC 6891), and properly implemented name servers should either reply with an EDNS0 compliant response, or provide a regular DNS response if they don’t understand.

However, a lot of name server software is not implemented properly which has meant resolvers have had to incorporate workarounds when name servers don’t respond correctly, but these cause unnecessary retries, delays, and prevent the newer features of the DNS being used. The vendors of the most commonly used DNS software (BIND, Ubound, PowerDNS and Knot) are therefore removing these workarounds as of 1 February 2019, with the consequence is that hostnames served by broken DNS implementations will no longer be resolved. So please check whether your domain is affected!

ASREN is a non-profit association of National Research and Education Networks in the Middle East that aims to connect institutes to enable access to services, applications and computing resources within the region and around the world, and to boost scientific research and cooperation amongst its members. Its mandate covers 22 countries, and it has partnered with the major regional R&E networking initiatives elsewhere in the world, including GÉANT (Europe), Internet2 (United States), CANARIE (Canada), WACREN (West Africa) and RedCLARA (Latin America). International connectivity is supported by the EU-funded EUMEDConnect3 project.

Deploy360 can also help you deploy DNSSEC, so please take a look at our Start Here page to learn more.

Further Information

Categories
Deploy360 Domain Name System (DNS) IETF Improving Technical Security Transport Layer Security (TLS)

Cloudflare launches 1.1.1.1 DNS service with privacy, TLS and more

There was an important development this month with the launch of Cloudflare’s new 1.1.1.1 DNS resolver service. This is a significant development for several reasons, but in particular it supports the new DNS-over-TLS and DNS-over-HTTPS protocols that allow for confidential DNS querying and response.

Why 1.1.1.1?

Before we get to that though, Cloudflare joins Google’s Public DNS that uses 8.8.8.8 and Quad9 DNS that uses 9.9.9.9, by implementing 1.1.1.1 as a memorable IP address for accessing its new DNS service. IP addresses are generally not as memorable as domain names, but you need access to a DNS server before you can resolve domain names to IP addresses, so configuring numbers is a necessity. And whilst a memorable IP address might be cool, it’s also proved important recently when DNS resolvers have been blocked or taken down, requiring devices to be pointed elsewhere.

The 1.1.1.1 address is part of the 1.1.1.0 – 1.1.1.255 public IP address range actually allocated to APNIC, one of the five Regional Internet Registries, but it has been randomly used as an address for so many things (e.g. for proxies), that it was overwhelmed with garbage traffic every time it was announced in the global routing system. The Cloudflare network is sufficiently scaled that it can cope with this traffic, so an agreement was established to allow APNIC Labs to analyse traffic to this address range in return for Cloudflare being able to use 1.1.1.1 for its DNS resolver project.

Under the agreement, APNIC also allowed Cloudflare to use the address 1.0.0.1 as the second IPv4 address for their DNS services, from a separate address range allocated for research. IPv6 addresses are also available, although at 2606:4700:4700::1111 and 2606:4700:4700::1001 they are not nearly so memorable.

Improving DNS Performance

It’s also important to have a fast and reliable DNS resolver service. Every device connecting to the Internet needs a recursive DNS resolver to translate names into addresses, which are usually provided by your ISP who’ll automatically configure your devices to point to them. However, ISP-provided resolvers can often be slow and unreliable (a problem I’ve encountered recently with an ISP that I use, and there’s some interesting comparison testing in this in this blog post), quite aside from the fact that locally-based servers have been blocked or censored by some national governments in response to civil unrest or politically embarrassing incidents. The likes of Cloudflare, Google, Quad9 and others provide alternatives, allowing users to choose better performing services with enhanced features rather than just having to rely on the default service offered by your ISP.

DNS Privacy

And this leads us to the most innovative feature of Cloudflare’s 1.1.1.1 DNS service. The DNS was never designed with privacy or security in mind, and whilst DNSSEC adds verification to the information returned by DNS queries, traffic is still sent unencrypted which allows anyone monitoring your network connection to see what you’re looking up and therefore visiting.

A couple of different solutions to this problem have recently been developed by the IETF, which we’ve discussed in previous blogs. The DPRIVE Working Group has developed DNS-over-(D)TLS, whilst the DOH Working Group has been working on DNS-over-HTTPS. The different protocols have different merits and try to address particular legacy behaviour of the DNS protocol (e.g. limitations on UDP packet size and the need for fast responses), but both approaches encrypt DNS queries and responses to provide confidentiality of these transactions.

So far so good, but there’s also a need for both resolvers and clients to be upgraded to support these protocols. Up until now, whilst some test servers have been set-up by various organisations, Google has been the only significant provider supporting DNS-over-HTTPS through their Google Public DNS and Android operating system. As a result, there’s been a certain reticence for other providers and vendors to build in support for protocols that rely on a competitor, but hopefully as more alternative resolver services are established, we’ll see increasing usage of these DNS privacy protocols.

Limitations

It should be pointed out that both DNS-over-HTTPS and DNS-over-TLS only encrypt DNS communications between stub-resolver (on the client device) and recursive resolver (e.g. Cloudflare 1.1.1.1). They do not currently encrypt the communications between the recursive resolver and authoritative DNS servers when resolving queries, so the provider of the resolver needs to be trusted as it still has the potential to monitor and log transactions. Neither does either protocol ensure the integrity of information returned from an authoritative server, which is why DNSSEC is also required to cryptographically assert the DNS entries are correct. They are nonetheless important components in improving the security and confidentiality of the DNS.

Implementation

If you’re interested in how to set-up a recursive DNS resolver and/or stub-resolver on a client device, you can find a lot of information over on the DNS Privacy website. Deploy360 also published a blog post last year on how we set-up DNS-over-TLS in the Go6lab which is well worth reading.

 


UPDATE: We should also note that Cloudflare’s 1.1.1.1 service also supports “Query Name (QNAME) Minimization”, as defined in RFC 7816. They include a reference to this at the end of their “Nitty Gritty Details” page:

Cloudflare minimizes privacy leakage by only sending minimal query name to authoritative DNS servers. For example, if a client is looking for foo.bar.example.com, the only part of the query 1.1.1.1 discloses to .com is that we want to know who’s responsible for example.com and the zone internals stay hidden.

Kudos to Cloudflare for implementing this higher level of privacy protection in their service.

Thanks to Stéphane Bortzmeyer for pointing out on Twitter that Cloudflare had implemented QNAME minimization. We had missed the small mention in Cloudflare’s technical blog post and weren’t aware they had included this.

 

Categories
Building Trust Deploy360 Domain Name System (DNS) IETF Internet of Things (IoT) IPv6 Open Internet Standards Transport Layer Security (TLS)

IETF 101, Day 3: TLS & DPRIVE is no Diet Coke

This week is IETF 101 in London, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. There’s plenty of variety on Wednesday, following the themes of Trust and Identity, IPv6 and the Internet-of-Things.

TLS has its second session of the week starting at 09.30 GMT/UTC, and will be focused on the big development of the TLS 1.3 specification being approved by the IESG. Some further work is required, but there are a number of TLS 1.3 related drafts up for discussion.

These include Datagram Transport Layer SecurityDTLS Connection Identifer,  Exported authenticators in TLSDANE Record and DNSSEC Authentication Chain Extension for TLS, TLS Certificate compression, SNI Encryption in Tunnelling via TLS, and Semi-static DH Key Establishment in TLS 1.3.


NOTE: If you are unable to attend IETF 101 in person, there are multiple ways to participate remotely.


Running in parallel is LPWAN which is working on enabling IPv6 connectivity with very low wireless transmission rates between battery-powered devices spread across multiple kilometres. There’s a draft providing an overview of the set of LPWAN technologies under consideration by the IETF, two other working group sponsored drafts on LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP, as well as five individual drafts related to SCHC.

After lunch there’s a choice of DPRIVE or 6TiSCH starting at 13.30 GMT/UTC.

DPRIVE will have two major topics of discussion, starting with recommendations for best current practices for those operating DNS privacy servers, building on the work of the DNS Privacy Project. There will also be a discussion on how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.

Finally, given that original focus of the Working Group was on stub-to-recursive-resolver connections which is now basically done from a standards perspective, there is interest in moving to next phase of privacy. A discussion on how to re-charter the group has therefore been scheduled.

6TiSCH has a full agenda, with the 6top protocol that enables distributed scheduling now being targeted for an IESG Last Call, and the security functionality (https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-05 and https://tools.ietf.org/html/draft-ietf-6tisch-6top-sfx-01) being prepared for Working Group Last Calls.

ACME rounds off the day from 15.30 GMT/UTC, where the main order of business is the core specification of the Automatic Certificate Management Environments that has been submitted to the IESG for publication. The meeting will also discuss the TLS ALPN challenge that allows for domain control validation using TLS, as well as using STIR with ACME to provide cryptographic authentication for telephone calls.

For more background, please read the Rough Guide to IETF 101 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) Events IETF IPv6

Deploy360@IETF99, Day 2: IoT, IPv6, DNSSEC, DPRIV & TLS

Tuesday is another hectic day at IETF 99 in Prague with a lot of relevant sessions for us. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

The morning starts at 09.30 CEST/UTC+2 with a very full V6OPS meeting (which continues on Thursday afternoon). There’s a couple of deployment case studies up first – on turning IPv4 off in the Microsoft enterprise network, followed by some experiences of using dual-stacked websites with Happy Eyeballs – before a presentation on the current status of IPv6 deployment.

There are ten drafts being discussed, including requirements for IPv6 routers that aims to document a set of IPv6 requirements for routers, switches and middle boxes based on design and architectural experiences; specifying requirements for zero-configuration IPv6 CPEs; and using conditional router advertisements for connecting an enterprise network to multiple ISPs using address space assigned by an ISP. Version 2 of Happy Eyeballs is also being proposed, tweaking the algorithm whereby a dual-stack host tries to establish connections with both IPv4 and IPv6; and there’s an interesting draft proposing deployment of IPv6-only Wi-Fi at IETF meetings.


NOTE: If you are unable to attend IETF 99 in person, there are multiple ways to participate remotely.


Running in parallel is DPRIVE, which will be discussing the DNS over the QUIC protocol, measuring the usage of DNS-over-TLS, as well as next steps. At the same time, PERC will be discussing a draft related to DTLS tunnelling.

First up in the afternoon at 13.30 CEST/UTC+2 is T2TRG which is reviewing the outcome of the Workshop on IoT Semantic/Hypermedia Interoperability (WISHI), and will discuss what its future activities and deliverables should be.

In the late afternoon session starting at 15.50 CEST/UTC+2, there’s DNSOP (which continues on Thursday afternoon). There doesn’t look to be much DNSSEC-wise on the agenda today, although there is a draft to enhance the automatic updating of DNSSEC trust anchor process (as specified in RFC 5011).

Also running in parallel is CFRG, which discusses and reviews cryptographic mechanisms for network security. There are five drafts being discussed, including on the transition from classical to post-quantum cryptography. In addition, there are two proposals for new cryptographic techniques.

If you’re interested in the Internet-of-Things, then you can also check-out 6LO. This group focuses on facilitating IPv6 connectivity over node networks with limited power, memory and processing resources, and will be discussing drafts on Neighbour Discovery, IPv6 over low-power Bluetooth mesh networks, and transmission of IPv6 over electrical power lines.

For more background, please read the Rough Guide to IETF 99 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups

Categories
Deploy360 IETF Transport Layer Security (TLS)

RFC 8094: DNS over DTLS published

RFC 8094 – DNS over Datagram Transport Layer Security (DTLS) – was recently published as an experimental specification.

This was the result of the ongoing activity of the DNS PRIVate Exchange (dprive) Working Group at the IETF to develop mechanisms to provide confidentiality to DNS transactions and to address concerns surrounding pervasive monitoring.

DNS queries and responses are normally exchanged unencrypted on the network between a DNS client and server, and can be monitored to reveal potentially sensitive information. RFC 8094 therefore proposes to use DTLS for encrypting queries and responses between DNS clients and servers.

The DTLS protocol is based on the Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees, but is more suited to datagram transport that supports low latency and loss tolerant communication but which does not require or provide reliable or in-order delivery of data.

As latency is critical for the DNS, the outlined specification aims to reduce DTLS round trips and reduce the DTLS handshake size, as well as minimise the computational load on the DNS servers. This is an experimental update to the DNS in order to evaluate implementations, interoperability and effect on the DNS infrastructure.

Further Information

Categories
Deploy360 Domain Name System (DNS) Events To archive Transport Layer Security (TLS)

Watch Live Today! DNS Privacy Workshop Streaming from NDSS 2017

lifeguard-beach

Want to learn the latest about DNS privacy? About the latest research and techniques to protect the confidentiality of your DNS info and queries?

Starting at 8:55 am PST (UTC-8) today, there will be what looks to be an outstanding workshop on DNS Privacy streaming live out of the Network and Distributed System Security Symposium (NDSS) in San Diego, California.

View the agenda of the DNS Privacy Workshop to see all the excellent sessions.  You can then join live at:

https://isoc.zoom.us/j/935912695

(Other remote connection options can be found at the bottom of the agenda page.)

Note – this workshop is not about DNSSEC, which is a method to protect the integrity of DNS (to ensure DNS info is not modified in transit), but rather new work being done within the IETF to improve the confidentiality of DNS.

The sessions include:

  • How DNS Works in Tor & Its Anonymity Implications
  • DNS Privacy through Mixnets and Micropayments
  • Towards Secure Name Resolution on the Internet – GNS
  • Changing DNS Usage Profiles for Increased Privacy Protection
  • DNS-DNS: DNS-based De-NAT Scheme
  • Can NSEC5 be practical for DNSSEC deployments?
  • Privacy analysis of the DNS-based protocol for obtaining inclusion proof
  • Panel Discussion: The Tension between DNS Privacy and DNS Service Management
  • The Usability Challenge for DNS Privacy and End Users
  • An Empirical Comparison of DNS Padding Schemes
  • DNS Service Discovery Privacy
  • Trustworthy DNS Privacy Services
  • EIL: Dealing with the Privacy Problem of ECS
  • Panel Discussion: DNS-over-TLS Service Provision Challenges: Testing, Verification, internet.nl

If you are not there in person (as I will not be), you can also follow along on the #NDSS17 hashtag on Twitter. There will also be tweets coming out of:

Stéphane Bortzmeyer will also be attending (and speaking at) the workshop – and he is usually a prolific tweeter at @bortzmeyer.

The sessions will also be recorded for later viewing. I’m looking forward to seeing the activity coming out of this event spur further activity on making DNS even more secure and private.

Please do follow along remotely – and please do share this information with other people you think might be interested. Thank you!


Image from Unsplash – I thought about showing the wide beaches, but the reality is that the conference participants won’t really get a chance to visit them. I thought “Lifeguard” was appropriate, though, because lifeguards are all about protecting people and keeping things safe.

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC)

Deploy360@IETF97, Day 5: TLS, DNS, DHCPv6 & Annyeonghi Gaseyo

Seoul SkylineThe final day at a IETF is usually pretty quiet for us, but not at the IETF 97. There’s four sessions of interest before we bid farewell to Seoul.

The first session on Friday morning at 09.30 KST (UTC+9), see the second part of the TLS meeting continuing on from where it left off on Tuesday. After that, it requires a bit of a juggling act as the Dynamic Host Configuration, DNS PRIVate Exchange, and CURves, Deprecating and a Little more Encryption Working Groups all start at 11.50 KST (UTC+9).


NOTE: If you are unable to attend IETF 97 in person, there are multiple ways to participate remotely.


In DHC there’s a proposed update to the DHCPv6 specification to add prefix delegation and stateless DHCPv6, along with an updated draft on DHCPv4 over DHCPv6 that provides a mechanism for dynamically configuring IPv4 over an IPv6-only network.

DPRIVE is working on securing the connections between the DNS clients and the recursive resolvers, using TLS and/or DTLS. This meeting will focus on the TLS and EDNS padding profiles whereby DNS messages are increased by a variable number of bytes to limit how much correlation can be made with well-known unencrypted packets. There will also be a discussion about Phase 2 of the group’s activities.

That just leaves CURDLE which is working on the cryptographic security of a number of protocols. Its very full agenda includes the specification of new algorithms for DNSSEC, along with those for SSH and CMS.

With that, it’s goodbye from us and onwards to Chicago. Many thanks for reading along this week… please do read our other IETF 97-related posts … and we’ll see you at IETF 98 on 26-31 March 2017!

Relevant Working Groups:

Categories
Community Networks Deploy360 Domain Name System Security Extensions (DNSSEC) IETF

Deploy360@IETF94, Day 1: IPv6, DPRIVE and TRANS

HTTPBIS session at IETF 92For the first day at IETF 94 in Yokohama, the attention of the Deploy360 team is going to be on IPv6, with the important IPv6 Operations Working Group (v6ops) and also on the DNS Privacy (DPRIVE) and certificate transparency (TRANS) working groups.

v6ops has a busy agenda this time, so much so that it’s running across two sessions curiously split between the 09.00-1130 UTC+9 block, and continuing later on during 17.10-19.10 UTC+9 block. Note also that the morning session will be held in Room 501, but proceedings move to Room 502 for the evening session.


NOTE: If you are unable to attend IETF 94 in person, there are multiple ways to participate remotely.


The draft draft-jjmb-v6ops-unique-ipv6-prefix-per-host has been generating significant discussion on the v6ops mailing list recently, which aims to address certain issues related to IPv6 deployment in community wi-fi scenarios. Another interesting draft with a luminary authorship is the operational recommendations for networks to assign multiple IPv6 addresses to end hosts to support usage of virtual machines, tethering, identifier-locator addressing and privacy amongst other applications.

Also worth following are drafts related to the operational implications of extension headers in IPv6 packets and how and where such packets are being dropped.

Other drafts up for discussion include a proposal for identifier-locator IPv6 addressing to support network virtualisation, an informational draft providing advice on routing-related design choices in IPv6 networks, and a proposed update of RFC 6145. If you can make it to the end of the day though, there will be a presentation of the work of David Plonka and Arthur Berger to improve classification and measurement methods for IPv6.

The DPRIVE Working Group will be meeting on Monday afternoon to dive into what look like some lengthy discussions about DNS over TLS and DNS over DTLS.  Stateless DNS encryption will also be discussed and there will be a general discussion of how to move the DPRIVE work forward.

All of this DPRIVE work is focused on securing the connection between DNS clients and the recursive resolvers that people use (such as those typically at an Internet Service Provider (ISP) or on the edge of a network) to add a layer of confidentiality.  We see this as an important part of the overall encryption work being done by the IETF to protect against the pervasive monitoring that we’ve seen on the Internet.  Mechanisms such as what DPRIVE is developing will raise the overall amount of trust in Internet-based communication.

Another group we don’t always monitor but will this time is the TRANS WG focused on “certificate transparency” (CT), a mechanism for tracking changes in TLS certificates.  The TRANS agenda includes some potential new work on logging of DNSSEC key changes in draft-zhang-trans-ct-dnssec.

For more background, please read the Rough Guide to IETF 94 from Andrei, Mat, Karen, Dan and myself.

Relevant Working Group:

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT)

Deploy360@IETF91, Day 2: UTA, DPRIVE, BGP in ANRP, 6LO and IOT, DNSOP

IETF 91 mic lineFor us at Deploy360, Day 2 of IETF 91 brings a heavy focus on DNSSEC and DNS security in general with both DNSOP and DPRIVE meeting. Today also brings one of the key working groups (UTA) related to our “TLS in Applications” topic area.  There is a key WG meeting related to using  IPv6 in “resource-constrained” environments such as the “Internet of Things” (IoT) … and a presentation in the Internet Research Task Force (IRTF) about BGP security and the RPKI.

These are, of course, only a very small fraction of the many different working groups meeting at IETF 91 today – but these are the ones that line up with the topics we write about here at Deploy360.

Read on for more information…


NOTE: If you are not in Honolulu but would like to follow along, please view the remote participation page for ways you can listen in and participate.  In particular, at this IETF meeting all the sessions will have Meetecho coverage so you can listen, watch and chat through that web interface.  All agenda times are in HST, which is UTC-10 (and five hours earlier than US Eastern time for those in the US). I suggest using the “tools-style” agenda as it has easy links to the chat room, Meetecho and other documents for each session.


In the morning 9:00-11:30 block we once again will be splitting ourselves across multiple working groups.  In Coral 2 will be the “Using TLS in Applications” (UTA) working group looking at how to increase the usage of TLS across applications.  The UTA WG is a key part of the overall work of the IETF in strengthening the Internet against pervasive monitoring and should be quite a well-attended session.  The UTA agenda includes multiple drafts related to TLS and email, a discussion of a proposal around “token binding” and what should be an involved discussion about the TLS “fallback dance”, i.e. what should happen when a TLS connection cannot be made at the requested level of security?

On the topic of UTA, I’ll note that one of the groups main documents, draft-ietf-uta-tls-bcp, a best practice document on “Recommendations for Secure Use of TLS and DTLS“, has a new version out that incorporates all of the feedback received to date.  This document should soon be at the point where it will enter the publication queue.

Meanwhile, over in the Kahili room the 6LO WG will be talking about using IPv6 in “resource-constrained” and low power environments. The work here is important for sensor/device networks and other similar “Internet of Things” (IoT) implementations.   Among the 6LO agenda items are a discussion of using IPv6 in near field communications (NFC) and what should be quite an interesting discussion around the challenges of using different types of privacy-related IPv6 addresses in a constrained environment.

Simultaneously over in Coral 4 will be the open meeting of the Internet Research Task Force (IRTF) and of particular interest will be the presentation by one of the winners of the Applied Networking Research Prize (ANRP) that is focused on BGP security and the Resource Public Key Infrastructure (RPKI).  As the IRTF open meeting agenda lists the abstract:

The RPKI (RFC 6480) is a new security infrastructure that relies on trusted authorities to prevent attacks on interdomain routing. The standard threat model for the RPKI supposes that authorities are trusted and routing is under attack. This talk discusses risks that arise when this threat model is flipped: when RPKI authorities are faulty, misconfigured, compromised, or compelled (e.g. by governments) to take certain actions. We also survey mechanisms that can increase transparency when RPKI authorities misbehave.

The slides for the presentation are online and look quite intriguing!

After that we’ll be spending our lunch time at the “ISOC@IETF” briefing panel that is focused this time on the topic of “Is Identity an Internet Building Block?”  While not directly related to our work here at Deploy360 we’re quite interested in the topic.  I will also be directly involved as I’ll be producing the live video stream / webcast of the event.  You can join in and watch directly starting at 11:45 am HST (UTC-10). It should be an excellent panel discussion!

As I described in my Rough Guide post about DNSSEC, the 13:00-15:00 block brings the first meeting of the new DPRIVE working group that is chartered to develop “mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring.”  The DPRIVE agenda shows the various documents under discussion – there are some very passionate views on very different perspectives… expect this session to have some vigorous discussion!

In the last 15:20-17:20 meeting block of the day we’ll focus on the DNS Operations (DNSOP) Working Group where the major DNSSEC-related document under discussion will be Jason Livingood’s draft-livingood-dnsop-negative-trust-anchors that has generated a substantial bit of discussion on the dnsop mailing list.  The DNSOP agenda contains a number of other topics of interest, including a couple added since the time I wrote about DNS for the Rough Guide.  The discussion about root servers running on loopback addresses should be interesting… and Brian Dickson (now employed by Twitter instead of Verisign) is bringing some intriguing new ideas about a DNS gateway using JSON and HTTP.

After all of that, they’ll let us out of the large windowless rooms (granted, in the dark of evening) for the week’s Social event that will apparently be a Hawaiian Luau.  After all the time inside it will be a pleasure to end the day in casual conversations outside. Please do look to find us and say hello… and if you are not here in Honolulu, please do join in remotely and help us make the Internet work better!

See also:

Relevant Working Groups

We would suggest you use the “tools-style” agenda to find links to easily participate remotely in each of these sessions.

UTA (Using TLS in Applications) WG
Tuesday, 11 Nov 2014, 900-1130, Coral 2
Agenda: https://tools.ietf.org/wg/uta/agenda
Documents: https://tools.ietf.org/wg/uta
Charter: https://tools.ietf.org/wg/uta/charter

6LO (IPv6 over Networks of Resource-constrained Nodes) WG
Tuesday, 11 Nov 2014, 900-1130, Kahili
Agenda: https://tools.ietf.org/wg/6lo/agenda
Documents: https://tools.ietf.org/wg/6lo
Charter: https://tools.ietf.org/wg/6lo/charter

IRTF (Internet Research Task Force) Open Meeting
Tuesday, 11 Nov 2014, 900-1130, Coral 4
Agenda: http://tools.ietf.org/agenda/91/agenda-91-irtfopen.html
Charter: https://irtf.org/

DPRIVE (DNS PRIVate Exchange) WG
Tuesday, 11 November 2014, 1300-1500 HST, Coral 5
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSOP (DNS Operations) WG
Tuesday, 11 November 2014, 1520-1720 HST, Coral 4
Agenda: https://datatracker.ietf.org/meeting/91/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/


For more background on what is happening at IETF 91, please see our “Rough Guide to IETF 91″ posts on the ITM blog:

If you are here at IETF 91 in Honolulu, please do feel free to say hello to a member of the Deploy360 team.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF

DPRIVE – New IETF Working Group On DNS Privacy

IETF LogoHow can we ensure the confidentiality of DNS queries to protect against pervasive monitoring?  What kind of mechanisms can be developed to increase the privacy of an individual’s DNS transactions?

After holding a BOF session (DNSE) at an earlier IETF meeting, the IETF has now chartered a new Working Group called DPRIVE (DNS PRIVate Exchange) to dig into this matter. Part of the WG charter states:

The set of DNS requests that an individual makes can provide an
attacker with a large amount of information about that individual.
DPRIVE aims to deprive the attacker of this information. (The IETF
defines pervasive monitoring as an attack [RFC7258])

The primary focus of this Working Group is to develop mechanisms that
provide confidentiality between DNS Clients and Iterative Resolvers,
but it may also later consider mechanisms that provide confidentiality
between Iterative Resolvers and Authoritative Servers, or provide
end-to-end confidentiality of DNS transactions. Some of the results of
this working group may be experimental. The Working Group will also
develop an evaluation document to provide methods for measuring the
performance against pervasive monitoring; and how well the goal is met.
The Working Group will also develop a document providing example
assessments for common use cases.

The group has adopted its first document for consideration, Stephane Bortzmeyer’s “DNS privacy considerations”, draft-bortzmeyer-dnsop-dns-privacy, and discussion has already begun on the “dns-privacy” mailing list.  This list is open to anyone to join. You can subscribe at:

https://www.ietf.org/mailman/listinfo/dns-privacy

and the archives are available at:

http://www.ietf.org/mail-archive/web/dns-privacy/current/maillist.html

While this group does not directly relate to the work we do here at Deploy360 related to DNSSEC, it is part of the overall effort to increase the security of the DNS, and so I thought it would be of interest to our readers.

If you are interested in monitoring what is being discussed about DNS privacy, or contributing to those discussions, I would definitely encourage you to subscribe and join in the conversations and the work to make the Internet more secure!