Discovery of Network-designated OSCORE-based Resolvers: Problem Statement
Internet-Draft draft-lenders-core-dnr-03
Martine Sophie Lenders
TUD Dresden University of Technology
Helmholtzstr. 10
Dresden
D-01069
Germany
martine.lenders@tu-dresden.de
Christian Amsüss
christian@amsuess.com
Thomas C. Schmidt
HAW Hamburg
t.schmidt@haw-hamburg.de
Matthias Wählisch
TUD Dresden University of Technology & Barkhausen Institut
Helmholtzstr. 10
Dresden
D-01069
Germany
m.waehlisch@tu-dresden.de
09 July 2024
Web and Internet Transport
Constrained RESTful Environments
CoRE
CoAP
DoC
DNR
SVCB
This document states problems when designing DNS SVCB records to discover endpoints that communicate over Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. As a consequence of learning about OSCORE, this discovery will allow a host to learn both CoAP servers and DNS over CoAP resolvers that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] for key exchange. Challenges arise because SVCB records are not meant to be used to exchange security contexts, which is required in OSCORE scenarios.
About This Document
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.
Introduction
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.
[RFC9460] 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 [RFC9461], [RFC9462] or, in a local network, by Router Advertisements and DHCP [RFC9463]. In all theses cases, the SvcParams is used, but supports only DNS transfer based on Transport Layer Security (TLS), namely DNS over TLS (DoT) [RFC7858], DNS over HTTPS (DoH) [RFC8484], and DNS over Dedicated QUIC (DoQ) [RFC9250]. The use of DoT, DoH, or DoQ, however, is not recommended in IoT scenarios.
DNS over CoAP [I-D.ietf-core-dns-over-coap] provides a solution for encrypted DNS in constrained environments. The Constrained Application Protocol (CoAP) [RFC7252] is mostly agnostic to the transport layer 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. [I-D.ietf-core-transport-indication] covers the selection of different CoAP transports using SVCB records.
CoAP offers three security modes:
- 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. Keys can be received from an ACE Authorization Server (AS), as described in the ACE OSCORE profile [RFC9203], or, alternatively to support "zero-touch", through an EDHOC key exchange [RFC9528], as described in the ACE EDHOC profile [I-D.ietf-ace-edhoc-oscore-profile].
The SVCB-based discovery of a CoAP service in mode "no security" is covered in [I-D.ietf-core-transport-indication], and a CoAP service in the mode "transport security" in [I-D.lenders-core-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
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.
Problem Space
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.
[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 is defined in [RFC8323]. As using the same ALPN ID for different transport layers is not recommended, another ALPN ID for CoAP over DTLS is introduced in [I-D.lenders-core-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 [I-D.ietf-core-transport-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 [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 when authentication is driven by Authorization for Constrained Environments (ACE) [RFC9203] [I-D.ietf-ace-edhoc-oscore-profile].
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:
- DoC over OSCORE using EDHOC, and
- DoC over OSCORE using ACE.
We mostly need to answer the question for additional SvcParamKeys. [RFC9460] defines the keys "mandatory", "alpn", "no-default-alpn", "port", "ipv4hint", and "ipv6hint". Additionally, [I-D.ietf-core-dns-over-coap] defines "docpath" which carries the path for the DNS resource at the DoC server as a CBOR sequence.
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 [RFC9463] needs to be evaluated in each case.
When using ACE, more SvcParamKeys might be needed, such as the OAuth audience, the scope or the authentication server URI.
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
This document has no IANA considerations.
References
Normative References
[RFC9460]

Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
B. Schwartz
M. Bishop
E. Nygren
November 2023
RFC 9460
DOI 10.17487/RFC9460
[RFC9461]

Service Binding Mapping for DNS Servers
B. Schwartz
November 2023
RFC 9461
DOI 10.17487/RFC9461
[RFC9462]

Discovery of Designated Resolvers
T. Pauly
E. Kinnear
C. A. Wood
P. McManus
T. Jensen
November 2023
RFC 9462
DOI 10.17487/RFC9462
[RFC9463]

DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)
M. Boucadair, Ed.
T. Reddy.K, Ed.
D. Wing
N. Cook
T. Jensen
November 2023
RFC 9463
DOI 10.17487/RFC9463
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC7252]

The Constrained Application Protocol (CoAP)
Z. Shelby
K. Hartke
C. Bormann
June 2014
RFC 7252
DOI 10.17487/RFC7252
[RFC7228]

Terminology for Constrained-Node Networks
C. Bormann
M. Ersue
A. Keranen
May 2014
RFC 7228
DOI 10.17487/RFC7228
[RFC7301]

Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
S. Friedl
A. Popov
A. Langley
E. Stephan
July 2014
RFC 7301
DOI 10.17487/RFC7301
[RFC7858]

Specification for DNS over Transport Layer Security (TLS)
Z. Hu
L. Zhu
J. Heidemann
A. Mankin
D. Wessels
P. Hoffman
May 2016
RFC 7858
DOI 10.17487/RFC7858
[RFC7959]

Block-Wise Transfers in the Constrained Application Protocol (CoAP)
C. Bormann
Z. Shelby, Ed.
August 2016
RFC 7959
DOI 10.17487/RFC7959
[RFC8323]

CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
C. Bormann
S. Lemay
H. Tschofenig
K. Hartke
B. Silverajan
B. Raymor, Ed.
February 2018
RFC 8323
DOI 10.17487/RFC8323
[RFC8484]

DNS Queries over HTTPS (DoH)
P. Hoffman
P. McManus
October 2018
RFC 8484
DOI 10.17487/RFC8484
[RFC8613]

Object Security for Constrained RESTful Environments (OSCORE)
G. Selander
J. Mattsson
F. Palombini
L. Seitz
July 2019
RFC 8613
DOI 10.17487/RFC8613
[RFC9250]

DNS over Dedicated QUIC Connections
C. Huitema
S. Dickinson
A. Mankin
May 2022
RFC 9250
DOI 10.17487/RFC9250
[RFC9203]

The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework
F. Palombini
L. Seitz
G. Selander
M. Gunnarsson
August 2022
RFC 9203
DOI 10.17487/RFC9203
[RFC9528]

Ephemeral Diffie-Hellman Over COSE (EDHOC)
G. Selander
J. Preuß Mattsson
F. Palombini
March 2024
RFC 9528
DOI 10.17487/RFC9528
[I-D.amsuess-core-coap-over-gatt]

CoAP over GATT (Bluetooth Low Energy Generic Attributes)
Christian Amsüss
18 March 2024
Internet-Draft draft-amsuess-core-coap-over-gatt-06
[I-D.ietf-ace-edhoc-oscore-profile]

Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)
Göran Selander
Ericsson
John Preuß Mattsson
Ericsson
Marco Tiloca
RISE
Rikard Höglund
RISE
8 July 2024
Internet-Draft draft-ietf-ace-edhoc-oscore-profile-05
[I-D.ietf-core-dns-over-coap]

DNS over CoAP (DoC)
Martine Sophie Lenders
TUD Dresden University of Technology
Christian Amsüss
Cenk Gündoğan
Huawei Technologies
Thomas C. Schmidt
HAW Hamburg
Matthias Wählisch
TUD Dresden University of Technology & Barkhausen Institut
28 June 2024
Internet-Draft draft-ietf-core-dns-over-coap-07
[I-D.ietf-core-transport-indication]

CoAP Transport Indication
Christian Amsüss
Martine Sophie Lenders
TUD Dresden University of Technology
8 July 2024
Internet-Draft draft-ietf-core-transport-indication-06
[I-D.lenders-core-coap-dtls-svcb]

Service Binding and Parameter Specification for CoAP over (D)TLS
Martine Sophie Lenders
TUD Dresden University of Technology
Christian Amsüss
Thomas C. Schmidt
HAW Hamburg
Matthias Wählisch
TUD Dresden University of Technology & Barkhausen Institut
21 June 2024
Internet-Draft draft-lenders-core-coap-dtls-svcb-00
[lwm2m]

White Paper – Lightweight M2M 1.1
OMA SpecWorks
October 2018
Change Log
Since draft-lenders-core-dnr-02
- Forward reference to upcoming changes in [I-D.ietf-core-transport-indication] updated
Since draft-lenders-core-dnr-01
- Remove parts specified in [I-D.ietf-core-transport-indication]
- Remove parts specified in [I-D.lenders-core-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
Acknowledgments
TODO acknowledge.