DRIP Entity Tags (DET) in the Domain Name System (DNS)
draft-ietf-drip-registries-18
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Adam Wiethuechter , Jim Reid | ||
| Last updated | 2024-10-17 (Latest revision 2024-09-27) | ||
| Replaces | draft-wiethuechter-drip-registries | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
INTDIR Early review
(of
-19)
by Ron Bonica
On the right track
DNSDIR Early review
by David Blacka
On the right track
DNSDIR Early review
(of
-09)
by Tim Wicinski
On the right track
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Associated WG milestones |
|
||
| Document shepherd | Daniel Migault | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | daniel.migault@ericsson.com |
draft-ietf-drip-registries-18
drip Working Group A. Wiethuechter, Ed.
Internet-Draft AX Enterprize, LLC
Intended status: Standards Track J. Reid
Expires: 31 March 2025 RTFM llp
27 September 2024
DRIP Entity Tags (DET) in the Domain Name System (DNS)
draft-ietf-drip-registries-18
Abstract
This document describes the discovery and management of DRIP Entity
Tags (DETs) in DNS. Authoritative Name Servers, with DRIP specific
DNS structures and standard DNS methods, are the Public Information
Registries for DETs and their related metadata.
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 31 March 2025.
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.
Wiethuechter & Reid Expires 31 March 2025 [Page 1]
Internet-Draft DET in DNS September 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. General Concept . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use of Existing DNS Models . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Required Terminology . . . . . . . . . . . . . . . . . . 4
2.2. Additional Definitions . . . . . . . . . . . . . . . . . 4
3. DET Hierarchy in DNS . . . . . . . . . . . . . . . . . . . . 5
4. Public Information Registry . . . . . . . . . . . . . . . . . 6
5. Canonical Public Registration Certificate . . . . . . . . . . 7
5.1. Private Information Registry URI . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. DRIP Prefix Delegation . . . . . . . . . . . . . . . . . 8
6.2. IANA DRIP Registry . . . . . . . . . . . . . . . . . . . 8
6.2.1. DRIP RAA Allocations . . . . . . . . . . . . . . . . 8
6.2.2. HHIT Entity Type . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. DNS Operational Considerations . . . . . . . . . . . . . 11
8. Public Key Exposure . . . . . . . . . . . . . . . . . . . . . 11
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. HHIT Resource Record . . . . . . . . . . . . . . . . 15
A.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Presentation Format . . . . . . . . . . . . . . . . . . . 15
A.3. Field Descriptions . . . . . . . . . . . . . . . . . . . 16
Appendix B. UAS Broadcast RID Resource Record . . . . . . . . . 16
B.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 16
B.2. Presentation Format . . . . . . . . . . . . . . . . . . . 17
B.3. Field Descriptions . . . . . . . . . . . . . . . . . . . 18
Appendix C. DET DNS Zone Examples . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
Registries are fundamental to Unmanned Aircraft System (UAS) Remote
Identification (RID). Only very limited operational information can
be sent via Broadcast RID, but extended information is sometimes
needed. The most essential element of information from RID is the
UAS ID, the unique key for lookup of extended information in relevant
registries (see Figure 4 of [RFC9434]).
When a DRIP Entity Tag (DET) [RFC9374] is used as the UAS ID in RID,
extended information can be retrieved from a DRIP Identity Management
Entity (DIME) which manages registration of and associated lookups
Wiethuechter & Reid Expires 31 March 2025 [Page 2]
Internet-Draft DET in DNS September 2024
from DETs. In this document we assume the DIME is a function of UAS
Service Suppliers (USS) (Appendix A.2 of [RFC9434]) but a DIME can be
independent or handled by another entity as well.
1.1. General Concept
DETs embedded a hierarchy scheme which is mapped onto DNS. DIME's
enforce registration and information access of data associated with a
DET while also providing the trust inherited from being a member of
the hierarchy. Other identifiers and their methods are out of scope
for this document.
Authoritative Name Servers of the Domain Name System (DNS) provide
the Public Information such as the cryptographic keys, endorsements
and certificates of DETs and pointers to Private Information
resources. Cryptographic (public) keys are used to authenticate
anything signed by a DET, such as in the Authentication defined
[RFC9575] for Broadcast RID. Endorsements and certificates are used
to endorse the claim of being part of the hierarchy.
Aspects of Private Information Registries to store and protect,
through AAA mechanisms, Personally Identifiable Information (PII) are
not described in this document.
1.2. Use of Existing DNS Models
DRIP relies on the DNS and as such roughly follows the registrant-
registrar-registry model. In DRIP, the registrant would be the end
user who owns/controls the Unmanned Aircraft. They are ultimately
responsible for the DET and any other information that gets published
in the DNS. Registrants use agents known as registrars to manage
their interactions with the registry. Registrars typically provide
optional additional services such as DNS hosting.
The registry maintains a database of the registered domain names and
their related metadata such as the contact details for domain name
holder and the relevant registrar. The registry provides DNS service
for the zone apex which contains delegation information for domain
names. Registries generally provide services such as WHOIS or RDAP
to publish metadata about the registered domain names and their
registrants and registrars.
Registrants have contracts with registrars who in turn have contracts
with registries. Payments follow this model too: the registrant buys
services from a registrar who pays for services provided by the
registry.
Wiethuechter & Reid Expires 31 March 2025 [Page 3]
Internet-Draft DET in DNS September 2024
By definition, there can only be one registry for a domain name.
Since that registry is a de facto monopoly, the scope of its
activities are usually kept to a minimum to reduce the potential for
market distortions or anti-competitive practices. A registry can
have an arbitrary number of registrars who compete with each other on
price, service and customer support.
It is not necessary, and in some case may not be desirable, for DRIP
registrations to strictly follow this registrant-registrar-registry
model. Prevailing circumstances and/or local policy may mean some
combination of these roles could be combined. A DRIP registry might
be operated by the CAA. Or it could be outsourced to a DNS registry
provider. Registration policies - pricing, renewals, registrar and
registrant agreements, etc. - will need to be developed. These
considerations SHOULD be determined by the CAA, perhaps in
consultation with local stakeholders. They are are out of scope for
this document.
The specifics for the UAS RID use case are detailed in the rest of
document.
1.3. Scope
The scope of this document is limited to the 2001:30::/28 IPv6 prefix
and its associated reverse domain in DNS for DETs being used in UAS
RID for participating parties (UA, Observer devices, DIMEs, etc.).
Other sectors may adopt this technology. It is RECOMMENDED that a
global Apex (i.e. IPv6 prefix) and international Apex manager be
designated for each sector.
2. Terminology
2.1. Required Terminology
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.
2.2. Additional Definitions
This document makes use of the terms (PII, USS, etc.) defined in
[RFC9153]. Other terms (DIME, Endorsement, etc.) are from [RFC9434],
while others (RAA, HDA, etc.) are from [RFC9374].
Wiethuechter & Reid Expires 31 March 2025 [Page 4]
Internet-Draft DET in DNS September 2024
3. DET Hierarchy in DNS
[RFC9374] defines the Hierarchical Host Identity Tag (HHIT) and
further specifies an instance of them used for UAS RID called DETs.
The HHIT is a 128-bit value that is as an IPv6 address intended
primarily as an identifier rather than locator. It's format is in
Figure 1 and further information is in [RFC9374].
+-------------+--------------+---------------+-------------+
| IPv6 Prefix | Hierarchy ID | HHIT Suite ID | ORCHID Hash |
| (28-bits) | (28-bits) | (8-bits) | (64-bits) |
+-------------+--------------+---------------+-------------+
/ \
/ \
/ \-----------------------------\
/ \
/ \
+--------------------------------+-----------------------+
| Registered Assigning Authority | HHIT Domain Authority |
| (14-bits) | (14-bits) |
+--------------------------------+-----------------------+
Figure 1: DRIP Entity Tag Breakdown
The IPv6 Prefix, assigned by IANA for DETs is 2001:30::/28. The
corresponding domain (nibble reversed as 3.0.0.1.0.0.2.ip6.arpa) is
owned by the IAB.
Due to the nature of the hierarchy split and its relationship to
nibble reversing of the IPv6 address, the upper level of hierarchy
(i.e. RAAs) "borrows" the upper two bits of their respective HDA
space for DNS delegation. As such the IPv6 prefix of RAAs are
2001:3x:xxx::/44 and HDAs are 2001:3x:xxxx:xx::/56 with respective
nibble reverse domains of x.x.x.x.3.0.0.1.0.0.2.ip6.arpa and
y.y.y.x.x.x.x.3.0.0.1.0.0.2.ip6.arpa.
Preallocations have been made based on the ISO 3166-1 Numeric Nation
Code [ISO3166-1]. This is to support the initial use case of DETs in
UAS RID on an international level. See Section 6.2.1 for the RAA
allocations.
The HDA values of 0, 4096, 8192 and 12288 are reserved for
operational use of an RAA (a by-product of the above mentioned
borrowing of bits), specifically when to register with the Apex and
endorse delegations of HDAs in their namespace.
Wiethuechter & Reid Expires 31 March 2025 [Page 5]
Internet-Draft DET in DNS September 2024
The administration, management and policy for operation a DIME at any
level in the hierarchy (Apex, RAA or HDA), be it external or from a
parent level, is out of scope for this document. In some cases, such
as the RAAs and HDAs of a nation, these are National Matters which
are to be dealt with by those parties accordingly.
4. Public Information Registry
Per [RFC9434] all information classified, by all parties involved, as
public is stored in the DNS, specifically Authoritative Name Servers,
to satisfy REG-1 from [RFC9153].
Authoritative Name Servers use domain names as handles and data is
stored in Resource Records (RR) with associated RRTypes. This
document defines two new RRTypes, one for HHIT metadata (HHIT,
Appendix A) and another for UAS Broadcast RID information (BRID,
Appendix B). The former RRType is particularly important as it
contains a URI (as part of the certificate) that point to Private
Information resources.
DETs, being IPv6 addresses, are to be under ip6.arpa (nibble reversed
per convention) with at minimum an HHIT RRType. Depending on local
circumstances or additional use cases other RRTypes MAY be present.
For UAS RID the BRID RRType MUST be present to provide the Broadcast
Endorsements defined in [RFC9575].
DNSSEC is strongly RECOMMENDED (especially for RAA-level and higher
zones). When a DIME decides to use DNSSEC they SHOULD define a
framework for cryptographic algorithms and key management [RFC6841].
This may be influenced by frequency of updates, size of the zone, and
policies.
UAS specific information, such as physical characteristics, MAY also
be stored in DNS but is out of scope for this document. This
specification information is currently drafted in [uas-sn-dns].
An example, from Apex to client, of the DNS zones in available in
Appendix C.
Lookups of the above RRTypes are performed with the standard DNS
methodology using the nibble reversed DET as the query name affixed
to the ip6.arpa domain apex and asking for the specific RRType. The
HHIT RRType provides the public key for signature verification and
URIs via the certificate. The BRID RRType provides static Broadcast
RID information such as the Broadcast Endorsements sent following
[RFC9575].
Wiethuechter & Reid Expires 31 March 2025 [Page 6]
Internet-Draft DET in DNS September 2024
5. Canonical Public Registration Certificate
The following is a canonical public registration certificate,
generated upon successful registration and placed into Appendix A.
It is defined here as X.509 and MAY be encoded as a C.509. Other
X.509 or C.509 MAY exist for specific use cases and MUST placed in
CERT RRTypes.
-----BEGIN CERTIFICATE-----
MIIBCTCBvKADAgECAhQsKjO1bWo9IQm4g6DnIDJmnQqRrDAFBgMrZXAwGTEXMBUG
A1UEAwwOMjAwMTAwM2ZmZTAwMDEwHhcNMjQwOTI1MjA0MTQ1WhcNMjQwOTI2MjA0
MTQ1WjAAMCowBQYDK2VwAyEAe9/qfhAvPzw/rWb5n4wmVfKZcUezxygo7qFDIO7z
TVejLzAtMB4GA1UdEQEB/wQUMBKHECABAD/+AAEFu+Gv+JeyXlowCwYDVR0PBAQD
AgeAMAUGAytlcANBACB7NmtdXksQDzkzVpJtl29H8g9EioEB75tNHQSSvlpjyFyO
uxKnOYUhN+fIuLhk4Inn79qbFhddGyVqFvcsfQk=
-----END CERTIFICATE-----
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
2c:2a:33:b5:6d:6a:3d:21:09:b8:83:a0:e7:20:32:66:9d:0a:91:ac
Signature Algorithm: ED25519
Issuer: CN = 2001003ffe0001
Validity
Not Before: Sep 25 20:41:45 2024 GMT
Not After : Sep 26 20:41:45 2024 GMT
Subject:
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
7b:df:ea:7e:10:2f:3f:3c:3f:ad:66:f9:9f:8c:26:
55:f2:99:71:47:b3:c7:28:28:ee:a1:43:20:ee:f3:
4d:57
X509v3 extensions:
X509v3 Subject Alternative Name: critical
IP Address:2001:3F:FE00:105:BBE1:AFF8:97B2:5E5A
X509v3 Key Usage:
Digital Signature
Signature Algorithm: ED25519
20:7b:36:6b:5d:5e:4b:10:0f:39:33:56:92:6d:97:6f:47:f2:
0f:44:8a:81:01:ef:9b:4d:1d:04:92:be:5a:63:c8:5c:8e:bb:
12:a7:39:85:21:37:e7:c8:b8:b8:64:e0:89:e7:ef:da:9b:16:
17:5d:1b:25:6a:16:f7:2c:7d:09
Figure 2: Example UA Canonical Registration Certificate
Wiethuechter & Reid Expires 31 March 2025 [Page 7]
Internet-Draft DET in DNS September 2024
5.1. Private Information Registry URI
The Public Information Registry MUST contain a pointer to a Private
Information Registry to obtain additional information associated with
an HHIT. The information available following a pointer MUST be
protected with a AAA mechanism, per REG-2 of [RFC9153]. The
definition of the AAA mechanism is out of scope for this document.
For DRIP, a URI extension in the X.509 (Section 5) is the selected
way to provide this information in DNS. A base URI, to perform
lookups, for a DIME MUST be included in their Canonical Registration
Certificate. A DIME MAY include a fully qualified URI in an
registering entities X.509 as needed.
These URI SHOULD use the path segment of Section 3.1.3
(domain/<domain name>) of [RFC9082]. The base URI is out of scope
for this document. The use of the RDAP bootstrap process is
OPTIONAL.
Additional URIs MAY be present in the X.509 for other use cases.
6. IANA Considerations
6.1. DRIP Prefix Delegation
This document requests that the IANA delegate the
3.0.0.1.0.0.2.ip6.arpa domain following instructions to be provided
by the IAB. Names within this zone are to be further delegated to
the appropriated RAA's described by this document.
6.2. IANA DRIP Registry
6.2.1. DRIP RAA Allocations
This document requests a new registry for RAA Allocations under the
DRIP registry group (https://www.iana.org/assignments/drip/
drip.xhtml) to be managed by IANA.
RAA Allocations: a 14-bit value used to represent RAAs. Future
additions to this registry are to be made through Expert Review
(Section 4.5 of [RFC8126]). The following values/ranges are
defined:
Wiethuechter & Reid Expires 31 March 2025 [Page 8]
Internet-Draft DET in DNS September 2024
+===============+===========+======================+===========+
| RAA Value(s) | Status | Allocation | Reference |
+===============+===========+======================+===========+
| 0 - 3 | Reserved | N/A | N/A |
+---------------+-----------+----------------------+-----------+
| 4 - 3999 | Allocated | ISO 3166-1 Countries | This RFC |
+---------------+-----------+----------------------+-----------+
| 4000 - 16375 | Reserved | N/A | N/A |
+---------------+-----------+----------------------+-----------+
| 16376 - 16383 | Allocated | DRIP WG | This RFC |
| | | (Experimental Use) | |
+---------------+-----------+----------------------+-----------+
Table 1
To support DNS delegation in ip6.arpa a single RAA is given 4
delegations by borrowing the upper two bits of HDA space. This
enables a clean nibble boundary in DNS to delegate from (i.e. the
prefix 2001:3x:xxx0::/44). These HDAs (0, 4096, 8192 and 12288) are
reserved for the RAA.
The mapping between ISO 3166-1 Numeric Numbers and RAAs can be found
as a CSV file on GitHub (https://github.com/ietf-wg-drip/draft-ietf-
drip-registries/blob/main/iso3166-raa.csv). Each Nation is assigned
four RAAs that are left to the national authority for their purpose.
For RAAs under this range a shorter prefix of 2001:3x:xx00::/40 MAY
be delegated to each CAA, which covers all 4 RAAs (and reserved HDAs)
assigned to them.
6.2.2. HHIT Entity Type
This document requests a new registry for HHIT Entity Type under the
DRIP registry group (https://www.iana.org/assignments/drip/
drip.xhtml).
HHIT Entity Type: numeric, 16-bit, field of the HHIT RRType to
encode the HHIT Entity Type. Future additions to this registry
are to be made through Expert Review (Section 4.5 of [RFC8126]).
The following values are defined:
+=======+===========================================+============+
| Value | Type | Reference |
+=======+===========================================+============+
| 0 | Not Defined | This RFC |
+-------+-------------------------------------------+------------+
| 1 | DRIP Identity Management Entity (DIME) | This RFC |
+-------+-------------------------------------------+------------+
| 2 | DIME: Authentication CA | [drip-dki] |
Wiethuechter & Reid Expires 31 March 2025 [Page 9]
Internet-Draft DET in DNS September 2024
+-------+-------------------------------------------+------------+
| 3 | DIME: Issuing CA | [drip-dki] |
+-------+-------------------------------------------+------------+
| 4 | Reserved | This RFC |
+-------+-------------------------------------------+------------+
| 5 | Apex | This RFC |
+-------+-------------------------------------------+------------+
| 6 | Apex: Authentication CA | [drip-dki] |
+-------+-------------------------------------------+------------+
| 7 | Apex: Issuing CA | [drip-dki] |
+-------+-------------------------------------------+------------+
| 8 | Reserved | This RFC |
+-------+-------------------------------------------+------------+
| 9 | Registered Assigning Authority (RAA) | This RFC |
+-------+-------------------------------------------+------------+
| 10 | RAA: Authentication CA | [drip-dki] |
+-------+-------------------------------------------+------------+
| 11 | RAA: Issuing CA | [drip-dki] |
+-------+-------------------------------------------+------------+
| 12 | Reserved | This RFC |
+-------+-------------------------------------------+------------+
| 13 | HHIT Domain Authority (HDA) | This RFC |
+-------+-------------------------------------------+------------+
| 14 | HDA: Authentication CA | [drip-dki] |
+-------+-------------------------------------------+------------+
| 15 | HDA: Issuing CA | [drip-dki] |
+-------+-------------------------------------------+------------+
| 16 | Uncrewed Aircraft (UA) | This RFC |
+-------+-------------------------------------------+------------+
| 17 | Ground Control Station (GCS) | This RFC |
+-------+-------------------------------------------+------------+
| 18 | Uncrewed Aircraft System (UAS) | This RFC |
+-------+-------------------------------------------+------------+
| 19 | Remote Identification (RID) Module | This RFC |
+-------+-------------------------------------------+------------+
| 20 | Pilot | This RFC |
+-------+-------------------------------------------+------------+
| 21 | Operator | This RFC |
+-------+-------------------------------------------+------------+
| 22 | Discovery & Synchronization Service (DSS) | This RFC |
+-------+-------------------------------------------+------------+
| 23 | UAS Service Supplier (USS) | This RFC |
+-------+-------------------------------------------+------------+
| 24 | Network RID Service Provider (SP) | This RFC |
+-------+-------------------------------------------+------------+
| 25 | Network RID Display Provider (DP) | This RFC |
+-------+-------------------------------------------+------------+
| 26 | Supplemental Data Service Provider (SDSP) | This RFC |
Wiethuechter & Reid Expires 31 March 2025 [Page 10]
Internet-Draft DET in DNS September 2024
+-------+-------------------------------------------+------------+
| 27 - | Reserved | N/A |
| 65535 | | |
+-------+-------------------------------------------+------------+
Table 2
Future additions to this registry MUST NOT be allowed if they can be
covered under an existing registration.
7. Security Considerations
7.1. DNS Operational Considerations
The Registrar and Registry are commonly used concepts in the DNS.
These components interface the DIME into the DNS hierarchy and thus
operation SHOULD follow best common practices, specifically in
security (such as running DNSSEC) as appropriate. The following RFC
provide suitable guidance: [RFC7720], [RFC4033], [RFC4034],
[RFC4035], [RFC5155], [RFC8945], [RFC2182], [RFC4786], [RFC3007].
If DNSSEC is used, a DNSSEC Practice Statement (DPS) SHOULD be
developed and published. It SHOULD explain how DNSSEC has been
deployed and what security measures are in place. [RFC6841]
documents a Framework for DNSSEC Policies and DNSSEC Practice
Statements.
The interfaces and protocol specifications for registry-registrar
interactions are intentionally not specified in this document. These
will depend on nationally defined policy and prevailing local
circumstances. It is expected registry-registrar activity will use
the Extensible Provisioning Protocol (EPP) [RFC5730]. The registry
SHOULD provide a lookup service such as WHOIS [RFC3912] or RDAP
[RFC9082] to provide public information about registered domain
names.
Decisions about DNS or registry best practices and other operational
matters SHOULD be made by the CAA, ideally in consultation with local
stakeholders. This document RECOMMENDS that DNSSEC SHOULD be used by
both Apex (to control RAA levels) and RAA (to control HDA level)
zones.
8. Public Key Exposure
DETs are built upon asymmetric keys. As such the public key must be
revealed to enable clients to perform signature verifications.
[RFC9374] security considerations cover various attacks on such keys.
Wiethuechter & Reid Expires 31 March 2025 [Page 11]
Internet-Draft DET in DNS September 2024
While unlikely the forging of a corresponding private key is possible
if given enough time (and computational power). As such it is
RECOMMENDED that the public key for any DET not be exposed in DNS
(under any RRType) until it is required.
Optimally this requires the UAS somehow signal the DIME that a flight
using a Specific Session ID will soon be underway or complete. It
may also be facilitated under UTM if the USS (which may or may not be
a DIME) signals when a given operation using a Session ID goes
active.
9. Contributors
Thanks to Stuart Card (AX Enterprize, LLC) and Bob Moskowitz (HTT
Consulting, LLC) for their early work on the DRIP registries concept.
Their early contributions laid the foundations for the content and
processes of this architecture and document. Bob Moskowitz is also
instrumental in the PKIX work defined in this document with his
parallel work in ICAO.
10. References
10.1. Normative References
[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/info/rfc2119>.
[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/info/rfc8174>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/info/rfc9374>.
[RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
2023, <https://www.rfc-editor.org/info/rfc9434>.
Wiethuechter & Reid Expires 31 March 2025 [Page 12]
Internet-Draft DET in DNS September 2024
10.2. Informative References
[drip-dki] Moskowitz, R. and S. W. Card, "The DRIP DET public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
moskowitz-drip-dki-09, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-moskowitz-
drip-dki-09>.
[F3411] ASTM International, "Standard Specification for Remote ID
and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
2022, <https://www.astm.org/f3411-22a.html>.
[ISO3166-1]
International Standards Organization (ISO), "Codes for the
representation of names of countries and their
subdivisions", ISO 3166-1:2020, DOI , August 2020,
<https://www.iso.org/iso-3166-country-codes.html>.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
DOI 10.17487/RFC2182, July 1997,
<https://www.rfc-editor.org/info/rfc2182>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
Wiethuechter & Reid Expires 31 March 2025 [Page 13]
Internet-Draft DET in DNS September 2024
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<https://www.rfc-editor.org/info/rfc6841>.
[RFC7720] Blanchet, M. and L. Liman, "DNS Root Name Service Protocol
and Deployment Requirements", BCP 40, RFC 7720,
DOI 10.17487/RFC7720, December 2015,
<https://www.rfc-editor.org/info/rfc7720>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
Wiethuechter & Reid Expires 31 March 2025 [Page 14]
Internet-Draft DET in DNS September 2024
[RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
Entity Tag (DET) Authentication Formats and Protocols for
Broadcast Remote Identification (RID)", RFC 9575,
DOI 10.17487/RFC9575, June 2024,
<https://www.rfc-editor.org/info/rfc9575>.
[uas-sn-dns]
Wiethuechter, A., "UAS Serial Numbers in DNS", Work in
Progress, Internet-Draft, draft-wiethuechter-drip-uas-sn-
dns-02, 25 June 2024,
<https://datatracker.ietf.org/doc/html/draft-wiethuechter-
drip-uas-sn-dns-02>.
Appendix A. HHIT Resource Record
This appendix is normative.
The HHIT Resource Record is a metadata record for various bits of
HHIT specific information that isn't available in the pre-existing
HIP RRType. It is encoded as a CBOR array.
A.1. Wire Format
The wire format for the HHIT RRType MUST be encoded in CBOR. The
CDDL of the RRType is provided in Figure 3.
hhit-rr = [
type: uint .size(2),
abbreviation: tstr .size(15),
registration-cert: bstr / #6.TBD
]
Figure 3: HHIT Wire Format CDDL
A.2. Presentation Format
The presentation format of the HHIT RRType MUST be in Extended
Diagnostic Notation as defined in Appendix G of [RFC8610]. Figure 4
provides an example of a HHIT RRType in this form. It is RECOMMENDED
to have all byte strings, except for IPv6 addresses, be displayed as
base64.
[
0,
"APEX",
WQGC..uAo=
]
Wiethuechter & Reid Expires 31 March 2025 [Page 15]
Internet-Draft DET in DNS September 2024
Figure 4: HHIT Presentation Format
A.3. Field Descriptions
HHIT Entity Type: This field is two octets with values defined in
Section 6.2.2. It is envisioned that there may be many types of
HHITs in use. In some cases it may be helpful to understand the
HHITs role in the ecosystem like described in [drip-dki]. This
field provides such context.
HID Abbreviation: This field is meant to provide an abbreviation to
the HID structure for display devices. The specific contents of
this field are not defined here.
Canonical Registration Certificate: This field is the canonical
registration certificate as described in Section 5 for the HHIT in
either X.509 DER or C.509 form.
Appendix B. UAS Broadcast RID Resource Record
This appendix is normative.
The UAS Broadcast RID Resource Record type (BRID) is a format to hold
public information typically sent of the UAS Broadcast RID that is
static. It can act as a data source if information is not received
over Broadcast RID or for cross validation.
B.1. Wire Format
The wire format for the BRID RRType MUST be encoded in CBOR. The
CDDL of the RRType is provided in Figure 5.
Wiethuechter & Reid Expires 31 March 2025 [Page 16]
Internet-Draft DET in DNS September 2024
bcast-rr = {
uas_type: nibble-field,
uas_ids: [+ uas-id-grp],
? auth: [+ auth-grp],
? self-grp,
? op_type: 0..3,
? area-grp,
? classification-grp,
? operator-grp
}
uas-id-grp = (
id_type: &uas-id-types,
uas_id: bstr .size(20)
)
uas-id-types = (none: 0, serial: 1, caa_id: 2, utm_id: 3, session_id: 4)
auth-grp = (
a_type: nibble-field,
a_data: bstr .size(1..362)
)
area-grp = (
area_count: 1..255,
area_radius: float,
area_floor: float,
area_ceiling: float
)
classification-grp = (
ua_class: 0..8,
eu_class: nibble-field,
eu_category: nibble-field
)
self-grp = (
desc_type: nibble-field,
description: tstr .size(23)
)
operator-grp = (
operator_id_type: nibble-field,
operator_id: bstr .size(20)
)
nibble-field = 0..15
Figure 5: BRID Wire Format CDDL
B.2. Presentation Format
The presentation format of the BRID RRType MUST be in Extended
Diagnostic Notation as defined in Appendix G of [RFC8610]. Figure 6
provides an example of a BRID RRType in this form. All byte strings
longer than 20 SHOULD be displayed as base64 when possible.
Wiethuechter & Reid Expires 31 March 2025 [Page 17]
Internet-Draft DET in DNS September 2024
{
"uas_type": 0,
"uas_ids": [
[4, h'012001003FFE0001056A2621D4EF572EF5']
],
"auths": [
[5, b64'AYDQ..dwo='],
[5, b64'AYDQ..Wgs='],
[5, b64'AYDQ..NAw='],
[5, b64'AYDQ..7gA=']
]
}
Figure 6: BRID Presentation Format
B.3. Field Descriptions
The field names and their general typing are borrowed from the ASTM
[F3411] data dictionary. See that document for additional
information on fields semantics and units.
Appendix C. DET DNS Zone Examples
This appendix is informative, showing an example of the DNS zone
setup/content from Apex to a client.
For this example the following DETs are shown:
* Apex = 2001:0030:0000:0005:fad8:7fea:e0f6:90ad
* RAA = 2001:003f:fe00:0005:618a:cd8e:76d3:b790
* HDA = 2001:003f:fe00:0105:ad79:a278:1c10:5443
* Client = 2001:003f:fe00:0105:6a26:21d4:ef57:2ef5
The RAA allocation of 16376 and an HDA of 1 have been selected.
$ORIGIN 3.0.0.1.0.0.2.ip6.arpa.
0.e.f.f IN NS ns1.raa-16376.example.com
1.e.f.f IN NS ns1.raa-16376.example.com
2.e.f.f IN NS ns1.raa-16376.example.com
3.e.f.f IN NS ns1.raa-16376.example.com
$ORIGIN 5.0.0.0.0.0.0.0.0.3.0.0.1.0.0.2.ip6.arpa.
d.a.0.9.6.f.0.e.a.e.f.7.8.d.a.f IN BRID ( a368..770a )
d.a.0.9.6.f.0.e.a.e.f.7.8.d.a.f IN HHIT ( 0 APEX 5901..b80a )
Wiethuechter & Reid Expires 31 March 2025 [Page 18]
Internet-Draft DET in DNS September 2024
Figure 7: Apex Zones
$ORIGIN 0.e.f.f.3.0.0.1.0.0.2.ip6.arpa.
1.0.0 IN NS ns1.hda-1.example.com
$ORIGIN 5.0.0.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.arpa.
0.9.7.b.3.d.6.7.e.8.d.c.a.8.1.6 IN BRID ( a368..5a0b )
0.9.7.b.3.d.6.7.e.8.d.c.a.8.1.6 IN HHIT ( 0 RAA 5901..0d0c )
Figure 8: RAA Zones
$ORIGIN 0.1.0.0.0.e.f.f.3.0.0.1.0.0.2.ip6.arpa.
3.4.4.5.0.1.c.1.8.7.2.a.9.7.d.a.5.0 IN BRID ( a368..340c )
3.4.4.5.0.1.c.1.8.7.2.a.9.7.d.a.5.0 IN HHIT ( 0 HDA 5901..ac0a )
5.f.e.2.7.5.f.e.4.d.1.2.6.2.a.6.5.0 IN BRID ( a368..ee00 )
5.f.e.2.7.5.f.e.4.d.1.2.6.2.a.6.5.0 IN HHIT ( 0 CHILD 5901..0306 )
Figure 9: HDA Zone
Authors' Addresses
Adam Wiethuechter (editor)
AX Enterprize, LLC
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Jim Reid
RTFM llp
St Andrews House
382 Hillington Road, Glasgow Scotland
G51 4BL
United Kingdom
Email: jim@rfc1035.com
Wiethuechter & Reid Expires 31 March 2025 [Page 19]