Discovery of Network-designated CoRE Resolvers

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 September 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[RFC9461], [RFC9462] and [RFC9463] specify options to discover DNS resolvers that allow for encrypted DNS resolution, using either DNS or, in a local network, Router Advertisements or DHCP. These specifications use Service Binding (SVCB) resource records or Service Parameters (SvcParams) to carry information required for configuration of such resolvers. So far, however, only DNS transfer protocols based on Transport Layer Security (TLS) are supported, namely DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], and DNS over Dedicated QUIC (DoQ) [RFC9250]. This document discusses and specifies options to discover DNS resolvers in constrained environments, mainly based on DNS over CoAP (DoC) [I-D.ietf-core-dns-over-coap].¶

DoC provides a solution for encrypted DNS in constrained environments. In such scenarios, the usage of DoT, DoH, DoQ, or similar TLS-based solutions is often not possible. The Constrained Application Protocol (CoAP) [RFC7252], the transfer protocol for DoC, is mostly agnostic to the transport layer, i.e., CoAP can be transported over UDP, TCP, or WebSockets [RFC8323], and even less common transports such as Bluetooth GATT [I-D.amsuess-core-coap-over-gatt] or SMS [lwm2m] are discussed.¶

CoAP offers three security modes, which would need to be covered by the SvcParams:¶

• No Security: This plain CoAP mode does not support any encryption. It is not recommended when using [I-D.ietf-core-dns-over-coap] but inherits core CoAP features such as block-wise transfer [RFC7959] for datagram-based segmentation. Such features are beneficial in constrained settings even without encryption.¶

• Transport Security: CoAP may use DTLS when transferred over UDP [RFC7252] and TLS when transferred over TCP [RFC8323].¶

• Object Security: Securing content objects can be achieved using OSCORE [RFC8613]. OSCORE can be used either as an alternative or in addition to transport security.¶

  OSCORE keys have a limited lifetime and need to be set up, for example through an EDHOC key exchange [I-D.ietf-core-oscore-edhoc], which may use credentials from trusted ACE Authorization Server (AS) as described in the ACE EDHOC profile [I-D.ietf-ace-edhoc-oscore-profile]. As an alternative to EDHOC, keys can be set up by such an AS as described in the ACE OSCORE profile [RFC9203].¶

To discover a DoC server via Discovery of Designated Resolvers (DDR) [RFC9462] and Discovery of Network-designated Resolvers (DNR) [RFC9463], the SvcParams field needs to convey both transfer protocol and type and parameters of the security parameters. We will specify extensions of SvcParams in this document.¶

2. Terminology

The terms “DoC server” and “DoC client” are used as defined in [I-D.ietf-core-dns-over-coap].¶

The terms “constrained node” and "constrained network" are used as defined in [RFC7228].¶

SvcParams denotes the field in either DNS SVCB/HTTPS records as defined in [RFC9460], or DHCP and RA messages as defined in [RFC9463]. SvcParamKeys are used as defined in [RFC9460].¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Problem Space

The first and most important question to ask for the discoverability of DoC resolvers is if and what new SvcParamKeys need to be defined.¶

[RFC9460] defines the “alpn” key, which is used to identify the protocol suite of a service binding using its Application-Layer Protocol Negotiation (ALPN) ID [RFC7301]. While this is useful to identify classic transport layer security, the question is raised if this is needed or even helpful for when there is only object security. There is an ALPN ID for CoAP over TLS that was defined in [RFC8323]. As using the same ALPN ID for different transport layers is not recommended, an ALPN for CoAP over UDP is being requested in Section 6. Object security may be selected in addition to transport layer security, so defining an ALPN ID for each combination might not be viable or scalable. For some ways of setting up object security, additional information is needed for the establishment of an encryption context and for authentication with an authentication server (AS). Orthogonally to the security mechanism, the transfer protocol needs to be established.¶

Beyond the SvcParamKeys, there is the question of what the field values of the Encrypted DNS Options defined in [RFC9463] might be with EDHOC or ACE EDHOC. While most fields map, “authentication-domain-name” (ADN) and its corresponding ADN length field may not matter in ACE driven cases.¶

Out of scope of this document are related issues adjacent to its problem space. they are listed both for conceptual delimitation, and to aid in discussion of more comprehensive solutions:¶

• There is ongoing work in addressing the trouble created by CoAP using a diverse set of URI schemes in the shape of coap+..., such as coap+tcp [I-D.ietf-core-transport-indication]. The creation of URI authority values that express the content of SVCB records together with IP literals is part of the solution space that will be explored there.¶

• Route Advertisements (RAs) as used in [RFC9463] can easily exceed the link layer fragmentation threshold of constrained networks. The presence of DNR information in an RA can contribute to that issue.¶

4. Solution Sketches

To answer the raised questions, we first look at the general case then 4 base scenarios, from which other scenarios might be a combination of:¶

• Unencrypted DoC,¶

• DoC over TLS/DTLS,¶

• DoC over OSCORE using EDHOC, and¶

• DoC over OSCORE using ACE-EDHOC.¶

In the general case, we mostly need to answer the question for additional SvcParamKeys. [RFC9460] defines the keys “mandatory”, “alpn”, “no-default-alpn”, “port”, “ipv4hint”, and “ipv6hint” were defined. Additionally, [RFC9461] defines “dohpath” which carries the URI template for the DNS resource at the DoH server in relative form.¶

For DoC, the DNS resource needs to be identified as, so a corresponding “docpath” key should be provided that provides either a relative URI or CRI [I-D.ietf-core-href]. Since the URI-Path option in CoAP may be omitted (defaulting to the root path), this could also be done for the “docpath”.¶

authenticator-domain-name: ""
ipv6-address: <DoC server address>
svc-params:
 - coaptransfer="tcp"
 - docpath="/dns"
 - port=61616

authenticator-domain-name: "dns.example.com"
ipv6-address: <DoC server address>
svc-params:
 - alpn="co"
 - docpath="/dns"

authenticator-domain-name: "dns.example.com"
ipv6-address: <DoC server address>
svc-params:
 - coaptransfer="udp",
 - objectsecurity="edhoc",
 - docpath="/dns",
 - port=61616

authenticator-domain-name: ""
ipv6-address: <DoC server address>
svc-params:
 - coaptransfer="tcp"
 - objectsecurity="edhoc" /* TBD: or ace-edhoc? */
 - docpath="/dns",
 - port=61616,
 - oauth-aud="dns.example.com",
 - oauth-scope="resolve DNS"
 - oauth-as="coap://as.example.com"

5. Security Considerations

TODO Security¶

6. IANA Considerations

Appendix A. Change Log

Acknowledgments

TODO acknowledge.¶

Authors' Addresses