| Internet-Draft | +CoRE DNR | +March 2024 | +
| Lenders, et al. | +Expires 5 September 2024 | +[Page] | +
This document specifies solutions to discover DNS resolvers that support +encrypted DNS resolution in constrained environments. The discovery is +based DNS SVCB records, Router Advertisements, or DHCP. In particular, the proposed +specification allows a host to learn DNS over CoAP (DoC) servers, including +configurations to use DoC over TLS/DTLS, OSCORE, and EDHOC when +resolving names.¶
+This note is to be removed before publishing as an RFC.¶
++ The latest revision of this draft can be found at https://anr-bmbf-pivot.github.io/draft-lenders-core-dnr/draft-lenders-core-dnr.html. + Status information for this document may be found at https://datatracker.ietf.org/doc/draft-lenders-core-dnr/.¶
++ Discussion of this document takes place on the + Constrained RESTful Environments Working Group mailing list (mailto:core@ietf.org), + which is archived at https://mailarchive.ietf.org/arch/browse/core/. + Subscribe at https://www.ietf.org/mailman/listinfo/core/.¶
+Source for this draft and an issue tracker can be found at + https://github.com/anr-bmbf-pivot/draft-lenders-core-dnr.¶
++ 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 5 September 2024.¶
++ 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.¶
+[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.¶
+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.¶
+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.¶
+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”.¶
+While unencrypted DoC is not recommended by [I-D.ietf-core-dns-over-coap] and might not even be viable using DDR/DNR, it +provides additional benefits not provided by classic unencrypted DNS over UDP, such as segmentation +block-wise transfer [RFC7959]. However, it provides the simplest DoC configuration and thus is +here discussed.¶
+At minimum for a DoC server a way to identify the following keys are required. “docpath” (see +above), an optional “port” (see [RFC9460]), the IP address (either with an optional +“ipv6hint”/“ipv4hint” or the respective IP address field in [RFC9463]), and a yet to be defined +SvcParamKey for the CoAP transfer protocol, e.g., “coaptransfer”. The latter can be used to identify +the service binding as a CoAP service binding.¶
+The “authenticator-domain-name” field should remain empty as it does not serve a purpose without +encryption.¶
+See this example for the possible values of a DNR option:¶
++authenticator-domain-name: "" +ipv6-address: <DoC server address> +svc-params: + - coaptransfer="tcp" + - docpath="/dns" + - port=61616 +¶ +
In addition to the SvcParamKeys proposed in Section 4.1, this scenario needs the +“alpn” key. While there is a “coap” ALPN ID defined, it only identifies CoAP over TLS [RFC8323]. +As such, a new ALPN ID for CoAP over DTLS is required.¶
+See this example for the possible values of a DNR option:¶
++authenticator-domain-name: "dns.example.com" +ipv6-address: <DoC server address> +svc-params: + - alpn="co" + - docpath="/dns" +¶ +
Note that “coaptransfer” is not needed, as it is implied by the ALPN ID; +thus, no values for it would be allocated for transfer protocols that use transport security.¶
+While the “alpn” SvcParamKey is needed for the transport layer security (see Section 4.2), +we can implement a CA-style authentication with EDHOC when using object security with OSCORE using +the authenticator-domain-name field.¶
+A new key SvcParamKey “objectsecurity” identifies the type of object security, using the value +"edhoc" in this scenario.¶
+See this example for the possible values of a DNR option:¶
++authenticator-domain-name: "dns.example.com" +ipv6-address: <DoC server address> +svc-params: + - coaptransfer="udp", + - objectsecurity="edhoc", + - docpath="/dns", + - port=61616 +¶ +
The use of objectsecurity="edhoc" with an authenticator-domain-name and no further ACE details indicates +that the client can use CA based authentication of the server.¶
+Using ACE, we require an OAuth context to authenticate the server in addition to the +“objectsecurity” key. We propose three keys “oauth-aud” for the audience, “oauth-scope” for the +OAuth scope, and “auth-as” for the authentication server. “oauth-aud” should be the valid domain +name of the DoC server, “oauth-scope” a list of identifiers for the scope, and “oauth-as” a valid +URI or CRI.¶
+TBD: should oauth-scope be expressed at all?¶
+Since authentication is done over OAuth and not CA-style, the “authenticator-domain-name” is not +needed. There might be merit, however, to use it instead of the “oauth-aud” SvcParamKey.¶
+See this example for the possible values of a DNR option:¶
++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" +¶ +
TODO Security¶
+The following entry is being requested for addition into the +"TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry, +which is part of the "Transport Layer Security (TLS) Extensions" group.¶
+ +Note that [RFC7252] does not prescribe the use of the ALPN TLS extension during connection the DTLS handshake. +This document does not change that, and thus does not establish any rules like those in Section 8.2 of [RFC8323].¶
+TODO acknowledge.¶
+| CoRE DNR | +plain text | +same as main | +
| CoRE DNR | +plain text | +same as main | +