Return to OSCORE problem statement only

draft-lenders-core-dnr.md

@@ -1,5 +1,5 @@
 ---
-title: "Discovery of Network-designated CoRE Resolvers"
+title: "Problem Statement for Discovery of Network-designated OSCORE-based Resolvers"
 abbrev: "CoRE DNR"
 category: info
 
@@ -49,27 +49,29 @@ author:
     email: [email protected]
 
 normative:
-  RFC7252: coap
-  RFC7301: alpn
-  RFC8613: oscore
   RFC9460: svcb
   RFC9461: svcb-for-dns
   RFC9462: ddr
   RFC9463: dnr
-  I-D.ietf-core-dns-over-coap: doc
-  I-D.ietf-core-oscore-edhoc: edhoc
 
 informative:
+  RFC7252: coap
   RFC7228: constr-nodes
+  RFC7301: alpn
   RFC7858: dot
   RFC7959: coap-block
   RFC8323: coap-tcp
   RFC8484: doh
+  RFC8613: oscore
+  RFC9176: core-rd
   RFC9250: doq
   RFC9203: ace-oscore
+  RFC9528: edhoc
   I-D.amsuess-core-coap-over-gatt: coap-gatt
   I-D.ietf-ace-edhoc-oscore-profile: ace-edhoc
-  I-D.ietf-core-href: cri
+  I-D.ietf-core-dns-over-coap: doc
+  I-D.ietf-core-transport-indication: coap-indication
+  # I-D.lenders-core-coap-dtls-svcb: coap-dtls-svcb
   lwm2m:
     title: White Paper – Lightweight M2M 1.1
     author:
@@ -79,37 +81,36 @@ informative:
 
 --- abstract
 
-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 document provides a problem statement for the discovery of endpoints that communicate over
+Object Security for Constrained RESTful Environments (OSCORE) {{-oscore}} over DNS SVCB records.
+This will ultimately allow a host to learn about CoAP servers, but also DNS over CoAP resolvers,
+that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) {{-edhoc}} for
+key exchange.
 
 --- middle
 
 # Introduction
 
-{{-svcb-for-dns}}, {{-ddr}} and {{-dnr}} 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
+{{-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}}. This document
-discusses and specifies options to discover DNS resolvers in constrained
-environments, mainly based on DNS over CoAP (DoC) {{-doc}}.
+(DoH) {{-doh}}, and DNS over Dedicated QUIC (DoQ) {{-doq}}.
 
-DoC provides a solution for encrypted DNS in constrained environments.  In
+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
 {{-coap-tcp}}, and even less common transports such as Bluetooth GATT {{-coap-gatt}} or SMS
-{{lwm2m}} are discussed.
+{{lwm2m}} are discussed. A future iteration of {{-coap-indication}} will cover the selection of this
+transport via SVCB records.
 
-CoAP offers three security modes, which would need to be covered by the SvcParams:
+Furthermore, 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
@@ -129,11 +130,15 @@ CoAP offers three security modes, which would need to be covered by the SvcParam
   As an alternative to EDHOC,
   keys can be set up by such an AS as described in the ACE OSCORE profile {{-ace-oscore}}.
 
-To discover a DoC server via Discovery of Designated Resolvers (DDR) {{-ddr}} and
-Discovery of Network-designated Resolvers (DNR) {{-dnr}}, 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 case of no security will be sufficiently covered by {{-coap-indication}}.
+{{-coap-tcp}} and \[TBD: -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.
 
 # Terminology
 
@@ -148,178 +153,79 @@ messages as defined in {{-dnr}}. SvcParamKeys are used as defined in {{-svcb}}.
 
 # 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.
+The first and most important point of discussion for the discoverability of CoAP is if and what
+new SvcParamKeys need to be defined and what is already there.
 
 {{-svcb}} defines the “alpn” key, which is used to identify the protocol suite of a service binding
 using its Application-Layer Protocol Negotiation (ALPN) ID {{-alpn}}. 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
-{{-coap-tcp}}. As using the same ALPN ID for different transport layers is not recommended, an ALPN for CoAP over UDP is being requested in {{iana}}. 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 {{-dnr}} 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.
+for when there is only object security. There is an ALPN ID for CoAP over TLS that is defined in
+{{-coap-tcp}}. As using the same ALPN ID for different transport layers is not recommended, another
+ALPN ID for CoAP over DTLS is introduced in \[TBD: -coap-dtls-svcb\]. Object security may be
+selected in addition to transport layer security or without it. Additionally, different
+CoAP transports can be selected, which may be orthogonal to the transport security.
+For instance, DTLS can be used over transports other than UDP. The selection of CoAP transport
+protocols will be covered in future versions of {{-coap-indication}}. Defining an ALPN ID for each
+combination of object security, mode of transport layer security, and transport protocol might not
+be viable or scalable. For some ways of setting up object security, additional information is
+needed, such as an establishment options for an encryption context with EDHOC or an authentication
+server (AS) with ACE.
+
+Beyond the SvcParamKeys, there is the question of what the field values of the Encrypted DNS Options
+defined in {{-dnr}} might be with EDHOC or ACE EDHOC. While most fields map,
+“authentication-domain-name” (ADN) and its corresponding ADN length field may not matter
+when authentication is driven by Authorization for Constrained Environments (ACE) {{-ace-oscore}}
+{{-ace-edhoc}}.
+
+# Objectives
+
+SVCB records are not meant and should not be used to exchange security contexts, so this eliminates
+scenarios that use pre-shared keys with OSCORE. This leaves 2 base scenarios for OSCORE, which may
+occur in combination, with scenarios using transport security, or alternative transport protocols:
 
-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.
+- DoC over OSCORE using EDHOC, and
+- DoC over OSCORE using ACE.
 
-* Route Advertisements (RAs) as used in {{-dnr}} can easily exceed the link layer fragmentation threshold of constrained networks.
-  The presence of DNR information in an RA can contribute to that issue.
+We mostly need to answer the question for additional SvcParamKeys. {{-svcb}} defines the keys
+“mandatory”, “alpn”, “no-default-alpn”, “port”, “ipv4hint”, and “ipv6hint”.
+Additionally, {{-doc}} defines “docpath” which carries the path for the DNS resource at the DoC
+server as a CBOR sequence.
 
-# Solution Sketches
+Since “alpn” is needed for transport layer security, the type of object security (OSCORE using
+EDHOC, OSCORE using ACE, OSCORE using EDHOC using ACE), needs to be conveyed in a different
+SvcParamKey. The semantics and necessacity of the authenticator-domain-name field in {{-dnr}} needs
+to be evaluated in each case.
 
-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:
+When using ACE, more SvcParamKeys might be needed, such as the OAuth audience, the scope or the
+authentication server URI.
 
-- 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. {{-svcb}}
-defines the keys “mandatory”, “alpn”, “no-default-alpn”, “port”, “ipv4hint”, and “ipv6hint” were
-defined. Additionally, {{-svcb-for-dns}} 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 {{-cri}}. Since the URI-Path option in CoAP may
-be omitted (defaulting to the root path), this could also be done for the “docpath”.
-
-## Unencrypted DoC {#sec:solution-unencrypted}
-While unencrypted DoC is not recommended by {{-doc}} 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 {{-coap-block}}. 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 {{-svcb}}), the IP address (either with an optional
-“ipv6hint”/“ipv4hint” or the respective IP address field in {{-dnr}}), 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
-~~~~~~~~
-
-## DoC over TLS/DTLS {#sec:solution-tls}
-In addition to the SvcParamKeys proposed in {{sec:solution-unencrypted}}, this scenario needs the
-“alpn” key. While there is a “coap” ALPN ID defined, it only identifies CoAP over TLS {{-coap-tcp}}.
-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.
-
-## DoC over OSCORE using EDHOC
-While the “alpn” SvcParamKey is needed for the transport layer security (see {{sec:solution-tls}}),
-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.
-
-## DoC over ACE-OSCORE
-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"
-~~~~~~~
+Defining these SvcParamKeys, including their value formats and spaces, as well as the behavior
+definition for authenticator-domain-name field, shall be part of future work.
 
 # Security Considerations
 
 TODO Security
 
-
 # IANA Considerations {#iana}
 
-## TLS ALPN for CoAP
-
-The following entry has been added to the
-"TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry,
-which is part of the "Transport Layer Security (TLS) Extensions" group.
-
-* Protocol: CoAP (over DTLS)
-* Identification sequence: 0x63 0x6f ("co")
-* Reference: {{-coap}} and \[this document\]
-
-Note that {{-coap}} 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 -coap-tcp}}.
-
+This document has no IANA considerations.
 
 --- back
 
 # Change Log
 
+## Since [draft-lenders-core-dnr-01]
+
+- Remove parts specified in {{-coap-indication}}
+- Remove parts specified in \[TBD: -coap-dtls-svcb\]
+- Remove solution sketches, set objectives to solve problem space
+
 ## Since [draft-lenders-core-dnr-00]
 
 - IANA has processed the "co" ALPN and it is now added to the registry
 
 [draft-lenders-core-dnr-00]: https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-00
+[draft-lenders-core-dnr-01]: https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-01
 
 # Acknowledgments
 {:numbered="false"}