Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF IPv6 Transport Layer Security (TLS)

Deploy360@IETF97, Day 2: DNS, TLS & More IPv6

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 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: