‹ Back
Deploy360 3 April 2016

[email protected], Day 1: IPv6, TLS, SIDR, DNSSD, ACME & REGEXT

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement
IETF95 Hackathon participants

It’s a very busy first day for the Deploy360 team at IETF 95 in Buenos Aires with our focus areas of IPv6, DNSSEC, securing BGP and TLS all having sessions during the day. Throughout this week at IETF 95 we’ll be bringing you these daily blog posts that point out what we are focused on during that day.

Our day begins with IPv6 Operations (v6ops), Secure Inter-Domain Routing (sidr) and Using TLS in Applications (uta) Working Groups all kicking-off at the same time on Monday afternoon at 14:00 ART (UTC-3). We’re then planning to take in the Extensions for Scalable DNS Service Discovery (dnssd) and Public Notary Transparency (trans) Working Groups, before finishing up the day with the Automated Certificate Management Environment (acme) and Registration Protocols Extensions (regext) Working Groups.

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

V6OPS only has a couple of drafts on the agenda this time, although the discussion of draft-gont-v6ops-ipv6-ehs-packet-drops-03 could be interesting as it concerns the observed issue of IPv6 packets with certain extension headers being dropped by Internet. The other draft under discussion draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02 is concerned with mitigating potential denial-of-service attacks via multicasting. However, also on the agenda is the LACNIC report on IPv6 deployment in Latin America and the Caribbean which is a comprehensive survey of the current state of IPv4 exhaustion, case studies of IPv6 deployments, as well as the problems, challenges and regulatory barriers that were experienced.

SIDR has quite a few new proposals on the agenda. The draft-rir-rpki-allres-ta-app-statement-00 attempts to address the problem where subordinate certificates over claim number resources leading to invalidation of the branch underneath and the potential loss of routing of those resources. This draft is expected to generate a lot of comment as it proposes that each RIR will move from a Trust Anchor reflecting their current holdings, to one reflecting all holdings so that over-claiming can not occur when resources are transferred from one RIR to another.

The draft-ietf-sidr-rpki-tree-validation-00 describes how a Relying Party can discover RPKI objects to download and validate independently from any repository access protocol is used, whilst draft-kklf-sidr-route-server-rpki-light-00 provides suggestions as to how RPKI can be effectively used in an IXP environment.

UTA has two new drafts up for discussion related to securing SMTP connections via TLS, whilst there’s a new version of the DEEP proposal which aims to improve email confidentiality between mail user agents and mail servers. As Dan York mentioned in a Rough Guide post, this UTA session has a strong DNSSEC connection as all of the proposals for securing email have some DNSSEC or DANE aspect.

Moving onto DNSSD which we haven’t covered too much in the past, but which is concerned with discovering services on a network that may extend beyond your own local network, with the security implications that entails. There are two interesting drafts here – one related to the overall threat model and the other about privacy extensions.

At the same time is TRANS which is focused on certificate transparency – a mechanism for tracking changes in TLS certificates. This has a draft out about the attack model and threats on certificate transparency that relates to our interest in TLS and DANE.

We round off the day with ACME which has been developing a standards-based REST API allowing agent software to authenticate that a server controls a domain, request a certificate, and then install it on a server without human intervention. This has been used in the Let’s Encrypt initiative, and this session will likely discuss whether the work of the group is now completed.

At the same time the REGEXT working group will be meeting for the first time with the goal of documenting extensions to the Extensible Provisioning Protocol (EPP) used for communication with top-level domain (TLD) registries.   This group is taking over from the now-closed EPPEXT working group which approved documents such as the process for a secure transfer of a DNSSEC-signed domain that is currently in the RFC editor queue for publication.   Our interest in this session at IETF 95 is draft-latour-dnsoperator-to-rrr-protocol, part of the ongoing work driven primarily by Olafur Gudmundsson (CloudFlare) and Jacques Latour (CIRA), with help from Paul Wouters and many others, to automate the process of passing the DNSSEC DS records from a DNS operator (or “DNS hosting provider”) up to a registry without involving a registrar.  Dan wrote about this issue last year and it has been a frequent topic at ICANN DNSSEC Workshops.

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

Relevant Working Groups:

Image credit: a photo Dan York took of part of the “DNS team” at the IETF 95 Hackathon that were working on DNS over TLS.

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...

Join the conversation with Internet Society members around the world