From f62cf9d862ff93c7e71fd6b7fdf9912824507cb4 Mon Sep 17 00:00:00 2001 From: Matthias Waehlisch Date: Sat, 29 Jun 2024 10:33:32 +0200 Subject: [PATCH] polish Introduction --- draft-lenders-core-dnr.md | 60 ++++++++++++++++----------------------- 1 file changed, 25 insertions(+), 35 deletions(-) diff --git a/draft-lenders-core-dnr.md b/draft-lenders-core-dnr.md index 722714f..b084674 100644 --- a/draft-lenders-core-dnr.md +++ b/draft-lenders-core-dnr.md @@ -63,7 +63,6 @@ informative: RFC8323: coap-tcp RFC8484: doh RFC8613: oscore - RFC9176: core-rd RFC9250: doq RFC9203: ace-oscore RFC9528: edhoc @@ -90,26 +89,27 @@ Challenges arise because SVCB records are not meant to be used to exchange secur # Introduction -{{-svcb}} specifies the "SVCB" ("Service Binding") DNS resource records to lookup information on -how to communicate with a service. Service Parameters (SvcParams) are used to -carry that information. On top of that, options to discover DNS resolvers that allow for encrypted -DNS resolution are specified in other document. These use either DNS ({{-svcb-for-dns}}, {{-ddr}}) -or, in a local network, Router Advertisements or DHCP ({{-dnr}}). These specifications use -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) {{-dot}}, DNS over HTTPS -(DoH) {{-doh}}, and DNS over Dedicated QUIC (DoQ) {{-doq}}. - -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) {{-coap}}, the transfer protocol for DoC, is mostly -agnostic to the transport layer, i.e., CoAP can be transported over UDP, TCP, or WebSockets +The discovery of Internet services can be facilitated by the Domain Name System (DNS). +To discover services of the constrained Internet of Things (IoT) using the DNS, two challenges must be solved. +First, the discovery of a DNS resolver that supports DNS resolution based on secure, IoT-friendly protocols---otherwise the subsequent discovery of IoT-tailored services would be limited to resolution protocols conflicting with constrained resources. +Second, the discovery of an IoT-friendly service beyond the DNS resolution. + +{{-svcb}} specifies the "SVCB" ("Service Binding") DNS resource record to lookup information needed to connect to a network service. Service Parameters (SvcParams) carry +that information within the SVCB record. + +The discovery of DNS resolvers can be enabled by the DNS itself {{-svcb-for-dns}}, {{-ddr}} or, in a local network, by Router Advertisements and DHCP {{-dnr}}. +In all theses cases, the SvcParams is used, but supports only DNS transfer based on Transport Layer Security (TLS), namely DNS over TLS (DoT) {{-dot}}, DNS over HTTPS (DoH) {{-doh}}, and DNS over Dedicated QUIC (DoQ) {{-doq}}. +The use of DoT, DoH, or DoQ, however, is not recommended in IoT scenarios. + +DNS over CoAP {{-doc}} provides a solution for encrypted DNS in constrained environments. +The Constrained Application Protocol (CoAP) {{-coap}} is mostly +agnostic to the transport layer +CoAP can be transported over UDP, TCP, or WebSockets {{-coap-tcp}}, and even less common transports such as Bluetooth GATT {{-coap-gatt}} or SMS -{{lwm2m}} are discussed. A future iteration of {{-coap-indication}} will cover the selection of this -transport via SVCB records. +{{lwm2m}} are discussed. +{{-coap-indication}} covers the selection of different CoAP transports using SVCB records. -Furthermore, CoAP offers three security modes: +CoAP offers three security modes: - **No Security:** This plain CoAP mode does not support any encryption. It is not recommended when using {{-doc}} but inherits core CoAP features @@ -122,22 +122,12 @@ Furthermore, CoAP offers three security modes: OSCORE {{-oscore}}. 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 {{-edhoc}}, - which may use credentials from trusted ACE Authorization Server (AS) - as described in the ACE EDHOC profile {{-ace-edhoc}}. - As an alternative to EDHOC, - keys can be set up by such an AS as described in the ACE OSCORE profile {{-ace-oscore}}. - -The case of no security will be sufficiently covered by {{-coap-indication}}. -{{-coap-tcp}} and {{-coap-dtls-svcb}} cover the case for transport security. -However, there is still a gap for object security. This document provides a problem statement for -what is needed to fill this gap. - -For simplicity, we will talk about the discovery CoAP servers in the following, even though the -discovery and configuration of DoC servers over DDR and DNR is currently the main use case for this, -as {{-core-rd}} already provides resource discovery, and consequently CoAP service discovery, for -constrained environments. + OSCORE keys have a limited lifetime and need to be set up. + Keys can be received from an ACE Authorization Server (AS), as described in the ACE OSCORE profile {{-ace-oscore}}, or, alternatively to support “zero-touch”, through an EDHOC key exchange {{-edhoc}}, as described in the ACE EDHOC profile {{-ace-edhoc}}. + +The SVCB-based discovery of a CoAP service in mode “no security” is covered in {{-coap-indication}}, and a CoAP service in the mode “transport security” in {{-coap-dtls-svcb}}. +The discovery of CoAP services in mode “object security” is not specified. +To guide future specifications, this document clarifies aspects when using SVCB in the context of CoAP and object security. # Terminology