‹ Back
Deploy360 14 November 2016

[email protected], Day 2: DNS, TLS & More IPv6

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

Seoul SkylineTuesday at IETF 97 in Seoul represents something of a mixed bag, with sessions on IPv6 DNS and TLS. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

First up is 6MAN on Tuesday morning at 09.30 KST (UTC+9). On the agenda are several updates to the IPv6 specification as currently defined in RFC 2460RFC 4291 and RFC 1981. Other drafts being discussed outline an optional mechanism for IPv6 Neighbour Discovery whereby hosts are instructed by routers to use router solicitations rather than multicast advertisements where it’s not desirable for all hosts to be continually woken-up; define a new control bit in IPv6 RA PIO flags to indicate that the receiving node is the exclusive receiver of traffic destined to any address within a prefix; specify requirements for IPv6 nodes; and specify a packet format for transporting IPv6 payloads to multiple IPv6 destinations using Bit Index Explicit Replication.

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

There’s a clash between the Domain Name System Operations (dnsop) and Privacy Enhanced RTP Conferencing (perc) Working Groups on Tuesday afternoon at 13.30 KST (UTC+9). So we’ll be having to split our efforts between those, before heading to the Transport Layer Security (tls) Working Group for the evening session starting at 15.50 KST (UTC+9).

DNSOP is currently discussing several DNSSEC-related drafts. One recently submitted draft suggests an approach to managing Reverse DNS in IPv6 for Internet Service Providers, as the common practice of providing in.addr.arpa information using one PTR record for every IPv4 address does not scale with IPv6. There’s also a trance of other updates, including Signaling Trust Anchor Knowledge in DNSSEC which specifies two different ways validating resolvers to signal which keys are being used in their chain-of-trust; Managing DS records from parent via CDS/CDNSKEY which describe policies for signalling changes when undertaking key rollovers, and on Aggressive use of NSEC/NSEC3 resource records to allow DNSSEC validating resolvers to generate negative answers within a particular range as well as positive answers
from wildcards.

PERC will be discussing just a couple of Deploy360 relevant drafts. The first defines a DTLS tunneling protocol that enables a Media Distribution Device (MDD) to facilitate key exchange between an endpoint and a Key Management Function (KMF); whilst SRTP Double Encryption Procedures defines procedures to allow an intermediary node to manipulate RTP parameters while still providing strong end-to-end security.

That just leaves the first session of TLS which has several issues on the agenda. One is whether to rebrand the forthcoming TLS 1.3 to TLS 2.0 given the significant changes in the specification. Another is the ongoing draft defining a new TLS extension to allow clients to perform DANE authentication of a TLS server certificate without needing to perform additional DNS record lookups. Finally, Delegated Credentials for TLS describes a mechanism to allow TLS servers to make delegated changes to certificates or cryptographic algorithms without breaking compatibility with clients.

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

Relevant Working Groups:

‹ 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