From 9dd030164a2fc653e3893aed1d085e7b794b9316 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Mon, 4 Mar 2024 12:30:46 +0000 Subject: [PATCH] Script updating gh-pages from df46989. [ci skip] --- .../draft-lenders-core-dnr.html | 1676 +++++++++++++++++ .../draft-lenders-core-dnr.txt | 527 ++++++ draft-lenders-core-dnr-00/index.html | 45 + index.html | 8 + 4 files changed, 2256 insertions(+) create mode 100644 draft-lenders-core-dnr-00/draft-lenders-core-dnr.html create mode 100644 draft-lenders-core-dnr-00/draft-lenders-core-dnr.txt create mode 100644 draft-lenders-core-dnr-00/index.html diff --git a/draft-lenders-core-dnr-00/draft-lenders-core-dnr.html b/draft-lenders-core-dnr-00/draft-lenders-core-dnr.html new file mode 100644 index 0000000..91e9c21 --- /dev/null +++ b/draft-lenders-core-dnr-00/draft-lenders-core-dnr.html @@ -0,0 +1,1676 @@ + + + + + + +Discovery of Network-designated CoRE Resolvers + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftCoRE DNRMarch 2024
Lenders, et al.Expires 5 September 2024[Page]
+
+
+
+
Workgroup:
+
Constrained RESTful Environments
+
Internet-Draft:
+
draft-lenders-core-dnr-latest
+
Published:
+
+ +
+
Intended Status:
+
Informational
+
Expires:
+
+
Authors:
+
+
+
M. S. Lenders
+
TU Dresden
+
+
+
C. Amsüss
+
+
+
T. C. Schmidt
+
HAW Hamburg
+
+
+
M. Wählisch
+
TU Dresden & Barkhausen Institut
+
+
+
+
+

Discovery of Network-designated CoRE Resolvers

+
+

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.

+

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

+
+
+ +
+
+ ▲

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

+
+
+

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

+
+
+
+
+

+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:

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

+
    +
  • +

    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-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap-05>.
+
+
[I-D.ietf-core-oscore-edhoc]
+
+Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and G. Selander, "Using Ephemeral Diffie-Hellman Over COSE (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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc9460>.
+
+
[RFC9461]
+
+Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, , <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, , <https://www.rfc-editor.org/rfc/rfc9462>.
+
+
[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, , <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-05, , <https://datatracker.ietf.org/doc/html/draft-amsuess-core-coap-over-gatt-05>.
+
+
[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-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile-03>.
+
+
[I-D.ietf-core-href]
+
+Bormann, C. and H. Birkholz, "Constrained Resource Identifiers", Work in Progress, Internet-Draft, draft-ietf-core-href-14, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-href-14>.
+
+
[I-D.ietf-core-transport-indication]
+
+Amsüss, C., "CoAP Protocol Indication", Work in Progress, Internet-Draft, draft-ietf-core-transport-indication-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-transport-indication-03>.
+
+
[lwm2m]
+
+OMA SpecWorks, "White Paper – Lightweight M2M 1.1", , <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, , <https://www.rfc-editor.org/rfc/rfc7228>.
+
+
[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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8323>.
+
+
[RFC8484]
+
+Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc9250>.
+
+
+
+
+
+
+
+

+Acknowledgments +

+

TODO acknowledge.

+
+
+
+
+

+Authors' Addresses +

+
+
Martine Sophie Lenders
+
TUD Dresden University of Technology
+
Helmholtzstr. 10
+
+D-01069 Dresden +
+
Germany
+ +
+
+
Christian Amsüss
+ +
+
+
Thomas C. Schmidt
+
HAW Hamburg
+ +
+
+
Matthias Wählisch
+
TUD Dresden University of Technology & Barkhausen Institut
+
Helmholtzstr. 10
+
+D-01069 Dresden +
+
Germany
+ +
+
+
+ + + diff --git a/draft-lenders-core-dnr-00/draft-lenders-core-dnr.txt b/draft-lenders-core-dnr-00/draft-lenders-core-dnr.txt new file mode 100644 index 0000000..db1058e --- /dev/null +++ b/draft-lenders-core-dnr-00/draft-lenders-core-dnr.txt @@ -0,0 +1,527 @@ + + + + +Constrained RESTful Environments M. S. Lenders +Internet-Draft TU Dresden +Intended status: Informational C. Amsüss +Expires: 5 September 2024 + T. C. Schmidt + HAW Hamburg + M. Wählisch + TU Dresden & Barkhausen Institut + 4 March 2024 + + + Discovery of Network-designated CoRE Resolvers + draft-lenders-core-dnr-latest + +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. + + 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 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 + 2. Terminology + 3. Problem Space + 4. Solution Sketches + 4.1. Unencrypted DoC + 4.2. DoC over TLS/DTLS + 4.3. DoC over OSCORE using EDHOC + 4.4. DoC over ACE-OSCORE + 5. Security Considerations + 6. IANA Considerations + 6.1. TLS ALPN for CoAP + 7. References + 7.1. Normative References + 7.2. Informative References + Acknowledgments + Authors' Addresses + +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”. + +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: + 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: + 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. + +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: + 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: + + authenticator-domain-name: "" + ipv6-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 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. + + * 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-05, 17 + November 2023, . + + [I-D.ietf-core-oscore-edhoc] + Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and + G. Selander, "Using Ephemeral Diffie-Hellman Over COSE + (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, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained + Application Protocol (CoAP)", RFC 7252, + DOI 10.17487/RFC7252, June 2014, + . + + [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, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [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, + . + + [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, . + + [RFC9461] Schwartz, B., "Service Binding Mapping for DNS Servers", + RFC 9461, DOI 10.17487/RFC9461, November 2023, + . + + [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, + . + + [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, + . + +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-05, 23 October 2023, + . + + [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-03, 23 October 2023, + . + + [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, + . + + [I-D.ietf-core-transport-indication] + Amsüss, C., "CoAP Protocol Indication", Work in Progress, + Internet-Draft, draft-ietf-core-transport-indication-03, + 23 October 2023, . + + [lwm2m] OMA SpecWorks, "White Paper – Lightweight M2M 1.1", + October 2018, . + + [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for + Constrained-Node Networks", RFC 7228, + DOI 10.17487/RFC7228, May 2014, + . + + [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, . + + [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in + the Constrained Application Protocol (CoAP)", RFC 7959, + DOI 10.17487/RFC7959, August 2016, + . + + [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, + . + + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS + (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, + . + + [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, + . + + [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over + Dedicated QUIC Connections", RFC 9250, + DOI 10.17487/RFC9250, May 2022, + . + +Acknowledgments + + TODO acknowledge. + +Authors' Addresses + + 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 diff --git a/draft-lenders-core-dnr-00/index.html b/draft-lenders-core-dnr-00/index.html new file mode 100644 index 0000000..d659567 --- /dev/null +++ b/draft-lenders-core-dnr-00/index.html @@ -0,0 +1,45 @@ + + + + anr-bmbf-pivot/draft-lenders-core-dnr draft-lenders-core-dnr-00 preview + + + + +

Editor's drafts for draft-lenders-core-dnr-00 branch of anr-bmbf-pivot/draft-lenders-core-dnr

+ + + + + + +
CoRE DNRplain textsame as main
+ + + diff --git a/index.html b/index.html index da72697..7de22fb 100644 --- a/index.html +++ b/index.html @@ -32,6 +32,14 @@

Preview for branch iana-for-alpn

diff with main +

Preview for branch draft-lenders-core-dnr-00

+ + + + + + +
CoRE DNRplain textsame as main

Preview for branch chrysn-alpha-changes