Discovery of Network-designated CoRE Resolvers
draft-lenders-core-dnr-01

Constrained RESTful Environments                           M. S. Lenders
Internet-Draft                                                TU Dresden
Intended status: Informational                                 C. Amsüss
Expires: 20 September 2024                                              
                                                           T. C. Schmidt
                                                             HAW Hamburg
                                                             M. Wählisch
                                        TU Dresden & Barkhausen Institut
                                                           19 March 2024

             Discovery of Network-designated CoRE Resolvers
                       draft-lenders-core-dnr-01

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.

About This Document

   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.

Status of This Memo

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

Lenders, et al.         Expires 20 September 2024               [Page 1]
Internet-Draft                  CoRE DNR                      March 2024

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Problem Space . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Solution Sketches . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Unencrypted DoC . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  DoC over TLS/DTLS . . . . . . . . . . . . . . . . . . . .   6
     4.3.  DoC over OSCORE using EDHOC . . . . . . . . . . . . . . .   7
     4.4.  DoC over ACE-OSCORE . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  TLS ALPN for CoAP . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  11
     A.1.  Since draft-lenders-core-dnr-00 . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

Lenders, et al.         Expires 20 September 2024               [Page 2]
Internet-Draft                  CoRE DNR                      March 2024

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].

Lenders, et al.         Expires 20 September 2024               [Page 3]
Internet-Draft                  CoRE DNR                      March 2024

   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.

Lenders, et al.         Expires 20 September 2024               [Page 4]
Internet-Draft                  CoRE DNR                      March 2024

   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”.

Lenders, et al.         Expires 20 September 2024               [Page 5]
Internet-Draft                  CoRE DNR                      March 2024

4.1.  Unencrypted DoC

   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

4.2.  DoC over TLS/DTLS

   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.

Lenders, et al.         Expires 20 September 2024               [Page 6]
Internet-Draft                  CoRE DNR                      March 2024

4.3.  DoC over OSCORE using EDHOC

   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.

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

Lenders, et al.         Expires 20 September 2024               [Page 7]
Internet-Draft                  CoRE DNR                      March 2024

   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

6.1.  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: [RFC7252] and [this document]

   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].

7.  References

7.1.  Normative References

   [I-D.ietf-core-dns-over-coap]
              Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C.,
              and M. Wählisch, "DNS over CoAP (DoC)", Work in Progress,
              Internet-Draft, draft-ietf-core-dns-over-coap-06, 4 March
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              core-dns-over-coap-06>.

   [I-D.ietf-core-oscore-edhoc]
              Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using Ephemeral Diffie-Hellman Over COSE

Lenders, et al.         Expires 20 September 2024               [Page 8]
Internet-Draft                  CoRE DNR                      March 2024

              (EDHOC) with the Constrained Application Protocol (CoAP)
              and Object Security for Constrained RESTful Environments
              (OSCORE)", Work in Progress, Internet-Draft, draft-ietf-
              core-oscore-edhoc-10, 29 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              oscore-edhoc-10>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7252>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8613>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [RFC9461]  Schwartz, B., "Service Binding Mapping for DNS Servers",
              RFC 9461, DOI 10.17487/RFC9461, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9461>.

   [RFC9462]  Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
              Jensen, "Discovery of Designated Resolvers", RFC 9462,
              DOI 10.17487/RFC9462, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9462>.

Lenders, et al.         Expires 20 September 2024               [Page 9]
Internet-Draft                  CoRE DNR                      March 2024

   [RFC9463]  Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
              and T. Jensen, "DHCP and Router Advertisement Options for
              the Discovery of Network-designated Resolvers (DNR)",
              RFC 9463, DOI 10.17487/RFC9463, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9463>.

7.2.  Informative References

   [I-D.amsuess-core-coap-over-gatt]
              Amsüss, C., "CoAP over GATT (Bluetooth Low Energy Generic
              Attributes)", Work in Progress, Internet-Draft, draft-
              amsuess-core-coap-over-gatt-06, 18 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-amsuess-core-
              coap-over-gatt-06>.

   [I-D.ietf-ace-edhoc-oscore-profile]
              Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund,
              "Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object
              Security for Constrained Environments (OSCORE) Profile for
              Authentication and Authorization for Constrained
              Environments (ACE)", Work in Progress, Internet-Draft,
              draft-ietf-ace-edhoc-oscore-profile-04, 4 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
              edhoc-oscore-profile-04>.

   [I-D.ietf-core-href]
              Bormann, C. and H. Birkholz, "Constrained Resource
              Identifiers", Work in Progress, Internet-Draft, draft-
              ietf-core-href-14, 9 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              href-14>.

   [I-D.ietf-core-transport-indication]
              Amsüss, C. and M. S. Lenders, "CoAP Transport Indication",
              Work in Progress, Internet-Draft, draft-ietf-core-
              transport-indication-05, 18 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              transport-indication-05>.

   [lwm2m]    OMA SpecWorks, "White Paper – Lightweight M2M 1.1",
              October 2018, <https://omaspecworks.org/white-paper-
              lightweight-m2m-1-1/>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/rfc/rfc7228>.

Lenders, et al.         Expires 20 September 2024              [Page 10]
Internet-Draft                  CoRE DNR                      March 2024

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/rfc/rfc7858>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7959>.

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8323>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

   [RFC9203]  Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
              "The Object Security for Constrained RESTful Environments
              (OSCORE) Profile of the Authentication and Authorization
              for Constrained Environments (ACE) Framework", RFC 9203,
              DOI 10.17487/RFC9203, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9203>.

   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
              Dedicated QUIC Connections", RFC 9250,
              DOI 10.17487/RFC9250, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9250>.

Appendix A.  Change Log

A.1.  Since draft-lenders-core-dnr-00
      (https://datatracker.ietf.org/doc/html/draft-lenders-core-dnr-00)

   *  IANA has processed the "co" ALPN and it is now added to the
      registry

Acknowledgments

   TODO acknowledge.

Authors' Addresses

Lenders, et al.         Expires 20 September 2024              [Page 11]
Internet-Draft                  CoRE DNR                      March 2024

   Martine Sophie Lenders
   TUD Dresden University of Technology
   Helmholtzstr. 10
   D-01069 Dresden
   Germany
   Email: martine.lenders@tu-dresden.de

   Christian Amsüss
   Email: christian@amsuess.com

   Thomas C. Schmidt
   HAW Hamburg
   Email: t.schmidt@haw-hamburg.de

   Matthias Wählisch
   TUD Dresden University of Technology & Barkhausen Institut
   Helmholtzstr. 10
   D-01069 Dresden
   Germany
   Email: m.waehlisch@tu-dresden.de

Lenders, et al.         Expires 20 September 2024              [Page 12]